Ну вот мы и вернулись к тому, с чего начинали: уверены ли вы, что подобные нетривиальные ситуации встречаются сколько-нибудь регулярно?
И тут у меня преимущество в виде игры на своём поле =). За семь с лишним лет ежедневного использования STL я такие случаи могу по пальцам пересчитать. Причём делали мы далеко не офисный софт, а местами даже такой, где требовалось работать в режиме реального времени. И вот там были и оптимизации под железо, и шаблонная магия, и ассемблерные вставки. Но всё это было написано единожды и загнано на низкий уровень, работа с которым уже осуществлялась простыми классическими средствами.
Делаю предположение-комплимент: ваша уверенность в практической нужности знания о внутреннем устройстве используемых инструментов, подкрепляемая личным опытом — следствие того, что вы в основном сосредоточены на задачах, требующих навыков архитектора =).
Сейчас посмотрел ваш профиль и опубликованные вами посты — и лишь укрепился в этом мнении =). Согласен, для вас подобные знания действительно незаменимая часть рабочего процесса. Но вы и далеко не средний программист, руками которых выполняется большая часть грязной работы при создании программных продуктов =).
Окей, согласен: заглянуть в исходники или узнать из документации, что в них написано — суть схожие вещи. И если допустить, что без знания внутреннего устройства программист остаётся в неведении, что и в каких случаях ему использовать — то да, такая информация полезна.
Впрочем, я всё же считаю, что потребность в таком знании — индикатор того, что не всё в порядке в датском королевстве. Пример того, как может быть иначе — стандартная библиотека C++. Если взять такие контейнеры, как vector, map или list, то из их описания в документации предельно ясно, для каких операций каждый из контейнеров использовать:
vector — там, данные можно пронумеровать и критична скорость доступа;
map — там, где критична скорость доступа к данным по нечисловому ключу (или даже числовому, если диапазон ключей сильно разрежен);
list — там, где критичны минимальные издержки при модификации последовательности с концов и сохранение валидности указателей на данные (итераторов) при любых операциях с контейнером.
И для этого совершенно не нужно знать внутреннюю реализацию этих контейнеров, тем более что различные компиляторы комплектуются различными реализациями STL, а брожение по внутренностям STL-шаблонов — занятие не из приятных.
Суши-бар в моём доме в Питере. Зал для некурящих — каморка на четыре с половиной столика, основной зал на 15+ столов — для курящих. Особой вентиляции нет, банальным сквозняком сигаретный дым заносится в соседний зал, в итоге возвращаешься домой, а одежда насквозь провоняла.
Куда жаловаться, чтобы в конкретном месте курение прекратилось? И есть ли реально для того законные основания?
Я скорее всего понял, что именно происходит, но до сих пор не понимаю, почему GSM устроен именно так, а не иначе. Ведь ответ «Это я», очевидно, содержит какой-то идентификатор аппарата, и простейшая защита от дурака, съедающая какое-то совсем смешное количество ресурсов, могла бы исключить либо серьёзно усложнить такую атаку. Были ли в то время какие-то объективные причины полагаться на добросовестность производителей телефонов настолько, чтобы не внедрять дополнительные механизмы проверки?
А какой механизм шифрования в данном случае аналогичен https в вашем примере? И что используется в качестве ключа шифрования? IMEI аппарата, производная от него, уникальная для каждого аппарата? Тогда базовая станция должна чётко знать, чьим ключом пользоваться, и внутри неё уже есть механизмы, позволяющие однозначно соотнести номр получателя звонка или СМС и аппарат, чьим ключом нужно производить шифрование. А коль так, то какой смысл в широковещательных запросах «Чей это звонок» или «Чья это СМС»?
Можно, конечно, проштудировать документацию и запомнить сложность основных операций List<> в том виде, в котором она там указана. Но гораздо проще узнать, что это «динамический массив с такой-то стратегией роста, а никакой не L1-список» — остальные выводы мозг сделает сам.
Но вот только фишка в том, что если внутренняя реализация списка стабильна — то коль знание о ней даёт такие профиты разработчику, то об этом можно просто написать в документации. Тогда и сложность операций описывать не придётся — «остальные выводы мозг сделает сам».
Если же внутренняя реализация не стабильна, и разработчики оставляют за собой право поменять её в будущих релизах, гарантируя лишь сохранность внешнего интерфейса — то и сложность операций, поддерживаемых списком, может не сохраниться.
В общем, я склонен полагать, что в конкретно вашем случае стремление заглянуть внутрь реализации — это скорее следствие недостатков документации. Возможно, так сделано специально, чтобы не плодить сущностей, а код реализации доступен и настолько понятен, что в комментариях не нуждается.
Тем не менее, это не может служить контрпримером к утверждению, что для сферического фреймворка в вакууме с не менее сферической документацией владения ею на сферическом уровне может быть вполне достаточно =).
Боюсь, не всё так просто =). Читаю я где-то с метра, а пишу, находясь на расстоянии около 80 см от экрана — иначе руки не дотягиваются до клавиатуры. И при этом «перешарпленность», наоборот, делает буквы очень читабельными.
Но я согласен, что к теме топика это не относится. Как и вся эта ветка =). Тем не менее, она полезна для формирования мотивации пробовать — ну или не пробовать — альтернативный браузер для тех, кто текущим решением не полностью доволен.
Эээ, как это так «не нуждаются в отдельном описании»? Вы как минимум должны знать, сколько там этих самых сотрудников. Ибо требования к софтине для внутреннего пользования компанией Microsoft будут несколько отличаться от таковых для компании «Рога и Копыта».
Если же РиК хочет получить себе продукт за три копейки, выдерживающий одновременный натиск гендиректора, секретарши и грузчика, то глупо потом предъявлять претензии разработчику, если они через какое-то время увеличатся на два-три порядка, ребренднутся во что-то более презентабельное и положат созданную для них ранее систему.
Хотите сказать, что только высококлассный спец знает отличия между списками и массивами? Тогда, увы, понятие «высокий класс» сильно девальвировалось, и его следует заменить на банальное «компетентность», соответственно, все «средние специалисты» на поверку оказываются некомпетентными.
Иногда единственный. Представления о реальной нагрузке может и не быть.
В таком случае я утверждаю, что для любого написанного кода можно написать код, выполняющий абсолютно те же функции, но более оптимально.
Если предела совершенству нет, то в какой момент остановиться? Такие вещи должны быть прописаны в ТЗ, в том числе параметры нагрузки, которую продукт должен выдерживать. С описанием параметров тестового стенда и показателями производительности, которые продукт должен обеспечивать. Если этого нет, то заказчик может требовать от вас оптимизации до бесконечности, и вы не сможете ему отказать.
Я сожалею, но приведённые вами примеры говорят не столько о необходимости читать исходники, сколько о слабости учебных материалов, прилагаемых к инструменту разработки. Либо, по логике создателей этого инструмента, его исходники являются частью таковых и, следовательно, обязательны к прочтению.
Впрочем, если пособие по стандартной библиотеке не может внятно объяснить преимущества и недостатки списков по сравнению с массивами — я всё же склонен полагать, что это вина такого пособия, а не доказательство утверждения об исключительной полезности изучения внутреннего строения библиотеки.
Что касается вашего примера с выравниванием записей в файле и необходимостью закапываться в уровень ОС или железа для выяснения оптимального решения — то это говорит скорее об использовании вами не подходящей для решения этой задачи технологии.
Одно дело — если вы пишете на C# код строго под винду, на 99% вас всё устраивает, и лишь в редких случаях возникают такие проблемы. Тогда можно говорить о том, что .NET Framework не предоставляет вам средств, позволяющих использовать особенности целевой системы для достижения нужной производительности. Тогда это вина .NET, и вам действительно нужно лезть в исходники, чтобы понять, как выкрутиться средствами C#, либо писать модуль для решения этой задачи с использованием более подходящей технологии и подключать его к остальной части проекта через некий общий интерфейс.
Другое дело — если такие проблемы часты. Тогда это уже не вина C#, .NET или чего-либо ещё. Это ваша вина, заключающаяся в том, что вы выбрали инструмент, не понимая, для решения каких задач он оптимален. И тут уж вам видней, как выкручиваться, но это и не должно быть проблемой: ведь, скорее всего, вам так привычен C#, что даже workaround'ы с его помощью будут даваться легче, чем освоение иных технологий.
Наконец, если вы пишете код, который предполагается использовать на различных платформах — то, желая получить оптимизацию сверх того, что можно достичь лишь с использованием стандартных средств, вы сами создаёте себе проблемы, идя против идеологии инструмента, подразумевающей работу в рамках фреймворка.
Опять же, если случаи, когда контроля, предоставляемого фреймворком, не хватает, редки — то вы в своём праве искать обходные пути по вашему желанию, благо любой такой фреймворк предоставляет возможность подцепить нативный код. А вот если эти проблемы случаются часто — то, скорее всего, вы выбрали не тот инструмент.
Резюмируя выше сказанное: разработчики, владеющие стандартными приёмами своих излюбленных инструментов, в 99% случаев справляются со своими задачами лишь с их помощью. Оставшийся один процент задач вполне может отдаваться узким спецам, владеющим мало кому знакомой магией, и в этом нет ничего криминального.
Если же пропорция между стандартными и нестандартными задачами перекошена в пользу нестандарта — то скорее всего что-то не так с архитектурой приложения либо с подбором команды для её реализации.
Иной раз очень сложно провести грань между наличием нужды и её отсутствием. Иногда профилирование возможно только в боевых условиях, когда отказы приводят к прямым потерям денег.
Не понимаю, как это: не понимать, нужно тебе что-то или нет.
Если мы говорим о проектах, разрабатываемых на заказ, то требования к производительности включаются в ТЗ (а если не включаются — то заказчик ССЗБ). В итоге уже на этапе приёмки работы должно становиться понятно, вписывается ли продукт в эти требования. Если да — всё чудесно, если нет — что ж, надо что-то делать.
Боевые условия — не единственный источник реалистичной нагрузки, на которой можно что-то проверять. Существуют средства автоматизации нагрузочного тестирования, и, уверен, даже для веб-проектов таковые имеются.
Или просто придумавшего отличное решение, которое намного эффективнее стандартных, но требует времени на осмысление. Грубый пример — решил перевести систему с SQL на NoSQL, а в команде ещё никто с последней не работал.
Пример не просто грубый — он некорректный. Перевод с SQL на NoSQL — это не выход за пределы стандартных решений, это смена стандартов. Понятно, что переход с одной технологии на другую — болезненный процесс для команды, но это не делает разработчиков дилетантами, а новую технологию панацеей. Условно говоря, разработчик, видя что этот проект переходит на технологию, которая ему не близка, может уйти на другой проект, где он по-прежнему сможет оставаться эффективным в рамках привычных ему стандартных решений, а вы сможете нанять NoSQL-разработчиков, для которых новый вектор развития продукта будет привычным и стандартным.
А насчёт эффективности отличного от стандартных «отличного решения» (это не тавтология, это игра слов =)): так же можно поступить в абсолютно любом проекте, сказав «Ребята, я придумал отличное решение: давайте перепишем всё с Python на ассемблер». В теории переход на более низкоуровневое кодирование может дать прирост в производительности итогового кода. Но на практике это приведёт к той самой ситуации, когда 90% времени разработчик будет пытаться понять, что он делает не так и что сделать, чтобы всё стало хорошо, не говоря уже об экспоненциально возросших временны́х расходах на разработку.
Вы сами прекрасно понимаете, что коммерческая разработка — это поиск баланса между производительностью продукта и производительностью процесса его создания и поддержки. Задача архитектора — подобрать такие стандартные решения, которые позволили бы реализовать именно то ви́дение баланса, за которое платит заказчик. После чего управленцы формируют команду разработчиков, для которых именно эти стандартные решения являются знакомыми и привычными.
Это всё в идеале. В реальности, знаю, всё сложнее: и заказчик меняет свои планы, и команда формируется не под один проект, и готовые специалисты под нужные технологии оказываются нанимателю не по карману. Но это издержки уже совершенно иного плана, не имеющие отношения к противопоставлению стандартных и нестандартных решений.
Раз уж вы сами помянули политдебаты всуе, то открою вам секрет: их суть — именно в том, чтобы упоминать и критиковать других кандидатов и их программы. Само слово debates означает «обсуждения, полемика, спор, прения». Изложение собственной программы — это лишь часть работы, другая важная часть — это найти изъяны в программах соперников и простым языком разъяснить оные потенциальным избирателям, следящим за дебатами. Это как peer review в научных журналах: так как немногие обладают достаточной квалификацией, чтобы разобраться в сути озвучиваемой проблемы, годной будет считаться лишь та публикация, которая прошла через руки независимых специалистов, заинтересованных в нахождении в ней ошибок, и получившая от них положительное заключение.
А чем вам нравятся шрифты в исполнении Safari на вашей картинке? Лично мне читать их сложнее, чисто на глаз буквы кажутся более размазанными и мыльными, в то время как версия Хрома — как и FF, силами которого отображена текстовая часть вашего комментария — прорисована идеально резко.
Не знаю, красота — понятие относительное. Может, это как-то связано с моим неприятием Apple Way в принципе, ибо во время вынужденного использования iMac'а в качестве рабочей станции на предыдущем месте работы я не испытывал ничего кроме фрустрации и желания пересесть на что угодно — обратно на винду, на линукс — лишь бы снова получить свободу видеть систему такой, какой она мне нравится, и работать с ней так, как мне нравится — а не как решили за меня умные дизайнеры из Apple.
Все технологические плюшки WebKit'а, я так понимаю, можно получить и в Хроме. Тамошние инструменты по работе с JavaScript мне тоже нравятся больше дефолтных из FF, и даже FireBug не решает эту проблему полностью (хотя, возможно, я не умею правильно им пользоваться). Но для потребления информации ничего милее FF я так и не нашёл, в том числе благодаря расширению Session Manager, хромовский тёзка которого даже рядом не стоял по функционалу.
Четыре гига — максимум что можно установить в мой ноут. Предлагать купить новый ноут не стоит: за исключением памяти, текущим полностью доволен =). Да и найти ноут с адекватной цветопередачей, FullHD экраном и возможностью подключить внешний 5.1 звук без цифрового ресивера сейчас найти проблематично, если вообще возможно.
Заодно отвечая на комментарий ниже: файл подкачки обратно включать не хочу, ибо тогда уже работа с диском становится узким местом, те же вкладки, ранее сохранённые на диск, извлекаются по полминуты, а закрытие браузера, до этого отожравшего два гига, превращается в процедуру на несколько минут, в течение которой тормозит теперь уже вся система. Плюс, от постоянной работы жёсткий диск сильно греется, и я боюсь что он таким макаром быстрее выйдет из строя.
В FF есть удобная опция: если вкладок стало слишком много — закрой браузер и открой заново: подгружаться будут только те вкладки, которые ты активируешь. У меня тоже мания наоткрывать миллион вкладок, и в условиях ограниченной памяти только такой метод спасает.
Недавно, кстати, ловил падение FF, причём после неоднократных предупреждений ОС о недостаточном количестве памяти, так что скорее всего причина в этом. Но при этом Хром у меня падает при схожих условиях гораздо чаще, причём не только отдельными вкладками, но и целиком, «Whoa, Google Chrome has crashed. Relaunch now?».
Не холивара ради, просто интересно: какой такой магической функциональностью обладает Safari, чтобы быть столь любимым своими пользователями несмотря на капризы? Что в нём есть, чего нет в FF и чего нельзя было бы добавить к нему с помощью расширения?
Просто моё знакомство с Safari было крайне мимолётным, чтобы составить о нём полноценное впечатление, но всё равно я с трудом могу себе представить, что в нём должно быть, чтобы даже с тормозами и вылетами можно было мириться.
и исчезновение такой практики примерно совпало с общим наступлением т. н. «политкорректности».
А вы уверены, что эта практика исчезла? Вот вам обзор вполне себе современных войн брендов, где указание на бренд соперника порой прописано явно. Да чего там далеко ходить, вспомните серию рекламных роликов «Hello I'm a Mac, and I'm a PC», там вся суть строится на конфронтации. И реклама вполне себе американская.
И тут у меня преимущество в виде игры на своём поле =). За семь с лишним лет ежедневного использования STL я такие случаи могу по пальцам пересчитать. Причём делали мы далеко не офисный софт, а местами даже такой, где требовалось работать в режиме реального времени. И вот там были и оптимизации под железо, и шаблонная магия, и ассемблерные вставки. Но всё это было написано единожды и загнано на низкий уровень, работа с которым уже осуществлялась простыми классическими средствами.
Делаю предположение-комплимент: ваша уверенность в практической нужности знания о внутреннем устройстве используемых инструментов, подкрепляемая личным опытом — следствие того, что вы в основном сосредоточены на задачах, требующих навыков архитектора =).
Сейчас посмотрел ваш профиль и опубликованные вами посты — и лишь укрепился в этом мнении =). Согласен, для вас подобные знания действительно незаменимая часть рабочего процесса. Но вы и далеко не средний программист, руками которых выполняется большая часть грязной работы при создании программных продуктов =).
Впрочем, я всё же считаю, что потребность в таком знании — индикатор того, что не всё в порядке в датском королевстве. Пример того, как может быть иначе — стандартная библиотека C++. Если взять такие контейнеры, как vector, map или list, то из их описания в документации предельно ясно, для каких операций каждый из контейнеров использовать:
vector — там, данные можно пронумеровать и критична скорость доступа;
map — там, где критична скорость доступа к данным по нечисловому ключу (или даже числовому, если диапазон ключей сильно разрежен);
list — там, где критичны минимальные издержки при модификации последовательности с концов и сохранение валидности указателей на данные (итераторов) при любых операциях с контейнером.
И для этого совершенно не нужно знать внутреннюю реализацию этих контейнеров, тем более что различные компиляторы комплектуются различными реализациями STL, а брожение по внутренностям STL-шаблонов — занятие не из приятных.
Куда жаловаться, чтобы в конкретном месте курение прекратилось? И есть ли реально для того законные основания?
Но вот только фишка в том, что если внутренняя реализация списка стабильна — то коль знание о ней даёт такие профиты разработчику, то об этом можно просто написать в документации. Тогда и сложность операций описывать не придётся — «остальные выводы мозг сделает сам».
Если же внутренняя реализация не стабильна, и разработчики оставляют за собой право поменять её в будущих релизах, гарантируя лишь сохранность внешнего интерфейса — то и сложность операций, поддерживаемых списком, может не сохраниться.
В общем, я склонен полагать, что в конкретно вашем случае стремление заглянуть внутрь реализации — это скорее следствие недостатков документации. Возможно, так сделано специально, чтобы не плодить сущностей, а код реализации доступен и настолько понятен, что в комментариях не нуждается.
Тем не менее, это не может служить контрпримером к утверждению, что для сферического фреймворка в вакууме с не менее сферической документацией владения ею на сферическом уровне может быть вполне достаточно =).
Но я согласен, что к теме топика это не относится. Как и вся эта ветка =). Тем не менее, она полезна для формирования мотивации пробовать — ну или не пробовать — альтернативный браузер для тех, кто текущим решением не полностью доволен.
Если же РиК хочет получить себе продукт за три копейки, выдерживающий одновременный натиск гендиректора, секретарши и грузчика, то глупо потом предъявлять претензии разработчику, если они через какое-то время увеличатся на два-три порядка, ребренднутся во что-то более презентабельное и положат созданную для них ранее систему.
В таком случае я утверждаю, что для любого написанного кода можно написать код, выполняющий абсолютно те же функции, но более оптимально.
Если предела совершенству нет, то в какой момент остановиться? Такие вещи должны быть прописаны в ТЗ, в том числе параметры нагрузки, которую продукт должен выдерживать. С описанием параметров тестового стенда и показателями производительности, которые продукт должен обеспечивать. Если этого нет, то заказчик может требовать от вас оптимизации до бесконечности, и вы не сможете ему отказать.
Впрочем, если пособие по стандартной библиотеке не может внятно объяснить преимущества и недостатки списков по сравнению с массивами — я всё же склонен полагать, что это вина такого пособия, а не доказательство утверждения об исключительной полезности изучения внутреннего строения библиотеки.
Что касается вашего примера с выравниванием записей в файле и необходимостью закапываться в уровень ОС или железа для выяснения оптимального решения — то это говорит скорее об использовании вами не подходящей для решения этой задачи технологии.
Одно дело — если вы пишете на C# код строго под винду, на 99% вас всё устраивает, и лишь в редких случаях возникают такие проблемы. Тогда можно говорить о том, что .NET Framework не предоставляет вам средств, позволяющих использовать особенности целевой системы для достижения нужной производительности. Тогда это вина .NET, и вам действительно нужно лезть в исходники, чтобы понять, как выкрутиться средствами C#, либо писать модуль для решения этой задачи с использованием более подходящей технологии и подключать его к остальной части проекта через некий общий интерфейс.
Другое дело — если такие проблемы часты. Тогда это уже не вина C#, .NET или чего-либо ещё. Это ваша вина, заключающаяся в том, что вы выбрали инструмент, не понимая, для решения каких задач он оптимален. И тут уж вам видней, как выкручиваться, но это и не должно быть проблемой: ведь, скорее всего, вам так привычен C#, что даже workaround'ы с его помощью будут даваться легче, чем освоение иных технологий.
Наконец, если вы пишете код, который предполагается использовать на различных платформах — то, желая получить оптимизацию сверх того, что можно достичь лишь с использованием стандартных средств, вы сами создаёте себе проблемы, идя против идеологии инструмента, подразумевающей работу в рамках фреймворка.
Опять же, если случаи, когда контроля, предоставляемого фреймворком, не хватает, редки — то вы в своём праве искать обходные пути по вашему желанию, благо любой такой фреймворк предоставляет возможность подцепить нативный код. А вот если эти проблемы случаются часто — то, скорее всего, вы выбрали не тот инструмент.
Резюмируя выше сказанное: разработчики, владеющие стандартными приёмами своих излюбленных инструментов, в 99% случаев справляются со своими задачами лишь с их помощью. Оставшийся один процент задач вполне может отдаваться узким спецам, владеющим мало кому знакомой магией, и в этом нет ничего криминального.
Если же пропорция между стандартными и нестандартными задачами перекошена в пользу нестандарта — то скорее всего что-то не так с архитектурой приложения либо с подбором команды для её реализации.
Не понимаю, как это: не понимать, нужно тебе что-то или нет.
Если мы говорим о проектах, разрабатываемых на заказ, то требования к производительности включаются в ТЗ (а если не включаются — то заказчик ССЗБ). В итоге уже на этапе приёмки работы должно становиться понятно, вписывается ли продукт в эти требования. Если да — всё чудесно, если нет — что ж, надо что-то делать.
Боевые условия — не единственный источник реалистичной нагрузки, на которой можно что-то проверять. Существуют средства автоматизации нагрузочного тестирования, и, уверен, даже для веб-проектов таковые имеются.
Пример не просто грубый — он некорректный. Перевод с SQL на NoSQL — это не выход за пределы стандартных решений, это смена стандартов. Понятно, что переход с одной технологии на другую — болезненный процесс для команды, но это не делает разработчиков дилетантами, а новую технологию панацеей. Условно говоря, разработчик, видя что этот проект переходит на технологию, которая ему не близка, может уйти на другой проект, где он по-прежнему сможет оставаться эффективным в рамках привычных ему стандартных решений, а вы сможете нанять NoSQL-разработчиков, для которых новый вектор развития продукта будет привычным и стандартным.
А насчёт эффективности отличного от стандартных «отличного решения» (это не тавтология, это игра слов =)): так же можно поступить в абсолютно любом проекте, сказав «Ребята, я придумал отличное решение: давайте перепишем всё с Python на ассемблер». В теории переход на более низкоуровневое кодирование может дать прирост в производительности итогового кода. Но на практике это приведёт к той самой ситуации, когда 90% времени разработчик будет пытаться понять, что он делает не так и что сделать, чтобы всё стало хорошо, не говоря уже об экспоненциально возросших временны́х расходах на разработку.
Вы сами прекрасно понимаете, что коммерческая разработка — это поиск баланса между производительностью продукта и производительностью процесса его создания и поддержки. Задача архитектора — подобрать такие стандартные решения, которые позволили бы реализовать именно то ви́дение баланса, за которое платит заказчик. После чего управленцы формируют команду разработчиков, для которых именно эти стандартные решения являются знакомыми и привычными.
Это всё в идеале. В реальности, знаю, всё сложнее: и заказчик меняет свои планы, и команда формируется не под один проект, и готовые специалисты под нужные технологии оказываются нанимателю не по карману. Но это издержки уже совершенно иного плана, не имеющие отношения к противопоставлению стандартных и нестандартных решений.
Не знаю, красота — понятие относительное. Может, это как-то связано с моим неприятием Apple Way в принципе, ибо во время вынужденного использования iMac'а в качестве рабочей станции на предыдущем месте работы я не испытывал ничего кроме фрустрации и желания пересесть на что угодно — обратно на винду, на линукс — лишь бы снова получить свободу видеть систему такой, какой она мне нравится, и работать с ней так, как мне нравится — а не как решили за меня умные дизайнеры из Apple.
Все технологические плюшки WebKit'а, я так понимаю, можно получить и в Хроме. Тамошние инструменты по работе с JavaScript мне тоже нравятся больше дефолтных из FF, и даже FireBug не решает эту проблему полностью (хотя, возможно, я не умею правильно им пользоваться). Но для потребления информации ничего милее FF я так и не нашёл, в том числе благодаря расширению Session Manager, хромовский тёзка которого даже рядом не стоял по функционалу.
Заодно отвечая на комментарий ниже: файл подкачки обратно включать не хочу, ибо тогда уже работа с диском становится узким местом, те же вкладки, ранее сохранённые на диск, извлекаются по полминуты, а закрытие браузера, до этого отожравшего два гига, превращается в процедуру на несколько минут, в течение которой тормозит теперь уже вся система. Плюс, от постоянной работы жёсткий диск сильно греется, и я боюсь что он таким макаром быстрее выйдет из строя.
Недавно, кстати, ловил падение FF, причём после неоднократных предупреждений ОС о недостаточном количестве памяти, так что скорее всего причина в этом. Но при этом Хром у меня падает при схожих условиях гораздо чаще, причём не только отдельными вкладками, но и целиком, «Whoa, Google Chrome has crashed. Relaunch now?».
Просто моё знакомство с Safari было крайне мимолётным, чтобы составить о нём полноценное впечатление, но всё равно я с трудом могу себе представить, что в нём должно быть, чтобы даже с тормозами и вылетами можно было мириться.
А вы уверены, что эта практика исчезла? Вот вам обзор вполне себе современных войн брендов, где указание на бренд соперника порой прописано явно. Да чего там далеко ходить, вспомните серию рекламных роликов «Hello I'm a Mac, and I'm a PC», там вся суть строится на конфронтации. И реклама вполне себе американская.