Так это не был плюс. Вы перечитайте выше, где я это упомянул ) Это была просто ремарка: «Для особо паранойных безопасников...». Ни к плюсам, ни к минусам она не относится )
1. Проекты бывают разные. Далеко не все из них позволят вам узнать, что они и где используют.
2. Называйте как хотите )
3. Чем отличается каждый раз при вызове скрипта запрашивать у БД шифрованные данные и расшифровывать их каждый раз в скрипте, и запрашивать у демона уже расшифрованные данные по тому же ключу или ID сессии? С чего вы взяли, что это решение более медленное?
4. Зависит от проекта. Некоторые делают исходя из возможности хостинга, некоторые — с расчетом callocation — то есть серваки стоят собственные. Есть проекты, требующие максимальной масштабируемости, есть — не требующие.
5.(про задержки) увеличте количество демонов, распределите нагрузку фиксированно и задержки будут более чем приемлемыми.
P.S. сколько можно повторять: я не настаиваю на конкретном решении. лишь предлагаю альтернативу, которая будет приемлема конечно же только в ограниченном количестве вариантов.
>> Решение использовать внешний демон или модуль к интерпретатору не так однозначно, надо тестировать и проверять.
Так а я что, разве настаиваю на конкретном решении? ))) Конечно надо расматривать альтернативы, взвешивать и тестировать. Я вроде об этом в основном и говорю.
>> Low-level программирования в статье, кстати, не было — использовали готовую библиотеку, так что тут с поддержкой всё ок.
Готовую, но чужую. Mcrypt поставляется вместе с PHP. Здесь заюзана чужая разработка(Ботан). В разных случаях это может дать разные нюансы.
Кроме того, здесь описана конкретная проблема и обсуждается конкретное решение. А если таких проблем и решений будет еще несколько? Проект обрастет библиотеками и чужими фреймворками… А вот имея уже готовый шаблонный демон, на него можно много чего повесить, учитывая, что он наботает бэкэндом, то есть работает где-то внутри системы на отдельных серверах, в конфигурации которых можно по-своему оптимизировать процессы.
Приходим к тому же, что вы и написали — надо садиться, рассматривать, думать, решать в каждом случае. Но при этом для начала полезно вообще видеть эти нюансы. Если люди о них не знают, это же не значит, что их нет. Это только значит, что они вероятно столкнутся с ними позже, возможно в не очень удобный момент )))
Ага. Верьте документации больше )))
У меня на фряхе плевался чужой памятью только в путь. В итоге косяк с адресацией был мой собственный и был обнаружен, но выплевывал чужую память в сокет уже не мой код. Там еще были некоторые решения, построенные на шаред мемори, возможно это одна из причин доступности чужой памяти на чтение «не нулей».
В общем сути это не меняет: я не говорил, что это обязательно, что явление частое и все такое. Просто предупредил, что такие проблемы тоже возможны и привел навскидку один из вариантов решения. Это так, между делом, к основной теме разговора конечно не относится.
Вы может быть не видите проблему достаточно глобально.
Есть множество нюансов как у варианта с демоном, так и у текущего варианта.
В каждом конкретном случае нужно эти нюансы рассматривать и уже потом решать.
Навскидку:
1. В крупных проектах заказчики любят в первую очередь масштабируемость. Им проще докупить серверов в стойки, чем оптимизировать отдельные куски. Особенно, если эти куски требуют такой низкоуровневой оптимизации. Иными словами демон, работающий с тем же стандартным mcrypt, но оптимизирующий само количество дешифраций, будет предпочтительнее в ряде случаев.
2. Демоны эти тоже можно сделать масштабируемыми. То есть серверов под них можно плодить сколько угодно и распределять между ними нагрузку.
3. Задержки канала связи с демоном, даже если он будет физически на другой машине, не всегда являются узким местом, даже если это кажется очевидным на первый взгляд. При правильном подходе для клиента просто страница будет генериться на доли секунды дольше. Во многих случаях это вполне приемлемо. Но серваки при этом не будут потеть от перегрузок. То есть упомянутое вами доп. время уже не связано напрямую с загрузкой процессоров. Иными словами общение с демоном мало чем будет отличаться от общения с основной БД например.
4. Библиотеку, напрямую прилинкованную к тому же PHP, нужно будет прикомпилировать к каждому новому вводимому в строй серверу. Кроме того, нужны будут люди, обслуживающие ее, то есть люди, разбирающиеся в этой низкоуровневой оптимизации и работе с инструкциями процессоров. Что получает заказчик после сдачи проекта и смены комманды разработчиков к примеру? Геморрой. Вот что он получает.
Так что тут еще вопрос, какой из вариантов считать костылями. Если серверов один-два, то вариант с бибилиотекой вполне прокатит — он действительно имеет более прямое использование и минимальный latency. Но судя по скудному описанию проекта в посте, проектик здесь достаточно крупный, чтобы дать приоритет масштабируемости.
Все относительно. Нагрузка конечно же есть. Но варианты мер против всплытия, типа сетки из тросов(или вертикальный корд, который мы видим на фото), имхо проще, чем попробовать то же давление заключить в шар на поверхности при внешней одной атмосфере. Тем более — «сила всплытия», она же выталкивающая, зависит от массы на объем. То есть получается, чем большее давление внутрь накачаем(а давление снаружи шара нам помогает его удержать, не раздувая шар), тем меньше сила всплытия. Иными словами, один и тот же объем(или масса) воздуха в шаре больше будет разрывать этот шар на поверхности, чем на глубине.
Как-то так.
P.S. С метеозондами и просто шариками с гелием то же самое — они лопаются сами, достигая определенной высоты — их просто разрывает изнутри в разреженной среде.
http-процесс может при нарушениях, вызванных к примеру атакой переполнения буффера, тупо выплюнуть во внешний сокет произвольный кусок памяти машины. Я с этим сталкивался раньше. Это так или иначе связано с человеческим фактором, то есть с косяками программистов, и подобные косяки со временем правятся, и они редкие, но тем не менее так бывает. Так вот. Есть вероятность, что туда могут попасть хранящиеся там дешифрованные данные в plain-виде.
Конечно, тут все зависит от конфигурации системы — демон можно выкинуть на отдельный сервак и все такое. Правда со всеми вытекающими задержками. Но во многих случаях они приемлемы, да и при распределении нагрузки(балансировке) локальный кеш каждого сервака особого смысла уже не имеет.
>> То есть, Вы просто третий раз повторили то, что я повторил во второй. :)
Совершенно верно )
Это я к вашему:
>> а ведь friq написал ровно то же самое, другими словами. Интересно, почему у меня это не осозналось при первом прочтении?
Мне показалось, про волынку более короткое и веселое объяснение. Я ж не знал, что вы про нее так мало знаете ))))
Да и вообще. Если кто-то потом это все будет читать, и не поймет с первого и второго раза, зато поймет с третьего или четвертого. Так что эти альтернативные объяснения вполне могут быть полезны )
Ну как я понял, в статье просто описывается один из вариантов решения.
А так я бы тоже сделал демон, который бы не просто делал постоянный декрипт одних и тех же данных, а к примеру хранил в памяти кеш расшифрованных данных, расшифровав их единожды в момент логина пользователя, и отдающий нужную их часть по запросу с ключем шифрования либо по идентификатору сессии.
Так оптимальнее.
Для особо паранойных безопасников есть вариант перешифровывать данные в памяти чем-то более простым типа RC4 — это защита на случай атак переполнения буфферов, когда при косяках в настройках серваков в HTTP-сокеты могут вываливаться дампы произвольных кусков памяти.
Музыкальный инструмент такой. Обычно принято его видеть в руках у шотландцев в клетчатых юбках(килтах).
Суть инструмента — буфферный кожаный мешок, прижимаемый локтем к телу. Есть трубка, через которую в мешок нагнетается воздух(вход), есть одна или несколько звукообразующих трубок(выходы). Для простоты примем один выход. В выходе встроена пищалка и дырки или поршни, изменяющие тон звука.
Постоянная скорость(давление) на выходе регулируется прижимом локтя, воздух поступает непостоянно — игроку нужны перерывы как минимум на вдох.
Однако за счет мешка-буффера при непостоянном и нерегулярном пополнении запаса воздуха волынка может играть условно вечно и при этом полное легато(переход между нотами без прерывания звука).
Так же есть электроволынки(с компрессором) и универсальные интрументы типа «человек-оркестр», где воздух может нагнетаться в мешок любым способом, например ножным насосом типа «лягушка».
Вот здесь мы имеем ровно то же самое — хоть ветряки наверху качают воздух в мешок непостоянно, за счет глубины и постоянного давления из мешка по отдельному каналу на турбину подается постоянный сглаженный поток воздуха. То есть от ветряка прямой отвод на турбину/генератор в общем-то и не нужен вовсе. Система стабилизирована. Отчасти это даже похоже на водонапорную башню — там принцип по сути тот же — держать на выходе константное давление.
Итого: тождественность законов физики во всей красе — давление в водонапорной башне, в этих мешках на 600-метровой глубине, напряжение в электросети — одного поля ягоды.
Не, ну как бы на поверхности ветряки торчать будут. И наверное же еще какие-то заграждения и предупреждения…
То есть спонтанно там судам и особенно лодкам делать как бы нечего )
>> Если я правильно понимаю — перепад давления воды и воздуха внутри шарика нулевой.
Да. В этом и есть часть идеи. Давление должны держать только сами стенки мешка — материал устойчивый к сплющиванию. «На разрыв» же нагрузка малая.
Во-первых вы и так в любой произвольный момент этого не знаете(и не надо ля-ля, что вы параноик и каждые 5 минут мультиметром в него тыкаете). А тут вам и индикатор в точке подключения выведут, и профиль по вашему желанию настроят, например не просаживать ниже 60-70%. Энергии для старта двигателя в любом случае оставят достаточно.
Если вы не поняли — ваш аккумулятор не собираются использовать, чтобы тупо выкачать из него накопленную вами энергию. Его будут использовать для сглаживания скачков в потреблении на районе например(ага, типа как LC-фильтры в блоках питания). Хотя частично по вашему желанию могут и выкачивать(за все те же льготы или взаимозачетом к вашим счетам за свет), если к примеру ваш ежедневный путь на работу и домой во многом состоит из стояния в пробках — при таком режиме работы двигла у вас все-равно с генератора избыток энергии идет.
Во-вторых. Да, износ будет больше при таких режимах. Однако зимой вы зато гарантированно заведетесь даже с изношенного аккумулятора, ибо простояв ночь на подключении к сети, он будет «прогрет» на момент старта двигла. На «крутануть немного стартер» хватит по-любому. А в обычном режиме замерз бы нафиг за ночь и все. Совсем хорошо, когда точки подключения к системе есть и на работе и дома.
Во-третьих это вообще дело добровольное. Не хочешь — не участвуй.
Кстати аппаратура в точке подключения вам так же подскажет приблизительную степень износа по графикам заряда/разряда за ночь, и соответственно вы будете точно знать, когда аккум пора менять. Сможете принять решение например перед дальней поездкой не наобум, как все делают обычно, а на основании вполне осязаемых цифр.
Понятное дело, что аппаратура в точках подключения должна состоять не тупо из двух клемм и амперметра. Если грамотно все реализовать, можно дойти вплоть до меток аккумуляторов(узнавание) и центральной БД, и многие вещи(от начислений бонусов до ведения пожизненной статистики состояния аккумулятора) будут делаться автоматически, даже если вы «воткнетесь» в точку в соседнем регионе.
Еще навскидку пришла мысль об льготной утилизации «меченного» аккумулятора. Чем не повод для поощрения? Когда не тупо выкинул, загаживая природу, а сдал в утиль, да еще и бонус за это вернул.
В общем, при желании можно реализовать немалое количество плюсов в этом методе.
По крайней мере между виндой и макосью нет. Даже расширение на винде не самоустанавливается, будучи установленным на маке(я сейчас на рабочем компе синхронизацию врубил).
Тут засада может быть в технических ограничениях. Дело в том, что это расширение от Яндекса — оно «продвинутое». То есть оно использует дополнительную скомпилированную библиотеку(ака DLL) для некоторых своих функций. И эти бинарники оно содержит для каждой поддерживаемой платформы свои.
Сами эти бинарники нужны для более полноценного контроля браузера, например чтобы перехватить создание новой вкладки. Я про эти методы даже где-то в документации гугля читал.
Собственно именно поэтому юзера так сильно хотят например полноценный букмарк-менеджер, но при этом никто не может написать таковой как стандартное расширение — в доступном для стандартных расширений API тупо не хватает функционала. А вот за счет плагинной библиотеки это сделать можно, но будет некроссплатформенно в большинстве случаев — ибо мало кто, написав либу под винду, будет писать порты на мак и линукс, и vise versa.
А Яндекс вот написал — то есть расширение работает в виндовс, макоси и линуксе. Но к сожалению не синхронизируется — как минимум кроссплатформно. Не знаю, синхронятся ли у хрома на одной платформе данные и настройкеи расширений или нет. Выделенной синхронизации у данного расширения тоже нет.
Это не всем доступно. Например я использую еще такое расширение, как Визуальные Закладки от Яндекса. chrome.google.com/webstore/detail/pchfckkccldkbclgdepkaonamkignanh
Оно как раз заменяет полностью стандартный интерфейс новой вкладки, и единственный его недостаток — нет этого списка последних закрытых вкладок.
Это компенсируется соответствующим разделом в главном меню на маке, либо в контекстном меню кнопки панели задач на виндовс. Но там в обоих случаях список коротковат. А данное расширение(секси анду таб) полезно как минимум тем, что ограничений в этом списке условно нет.
А вы не читали описание плагина? Это и есть интерфейс к гугль-калькулятору, которым вы фактически только что считали. Никто этого и не скрывает )))
Удобство здесь в том, что он делает из гугль-калькулятора некое подобие коммандной строки — в ней запоминаются все введенные расчеты(история), по клавише «вверх» можно выбрать что-либо, введеное ранее и т.п. И это доступно в виде кнопки на тулбаре — не нужны лишние действия по созданию новой вкладки, переключению между вкладками с данными(прайслистом магазина) и вкладкой с гуглем. Ну и т.п. Просто удобный ГУЙ к калькулятору гугля в общем…
И еще там можно поставить доп.плагин для возможности назначить хоткей вызова и локальный URL поисковой машины. google.ru вместо google.com например — если охота, чтоб результаты выдавались на русском.
Cloudy Calculator: chrome.google.com/webstore/detail/acgimceffoceigocablmjdpebeodphgc
Пользую постоянно для расчетов вида:
1133 eur in rur
(780.67+37.82) eur in rur
((705*2)-1000)*0.3
(0x0C*12) in hex
0xFCF09512 in decimal
12mm in inches
0.37 inches in mm
и т.п.
Но в основном конечно для переводов валют, рассчета таможенных пошлин и т.п. при заказе посылок из-за бугра.
2. Называйте как хотите )
3. Чем отличается каждый раз при вызове скрипта запрашивать у БД шифрованные данные и расшифровывать их каждый раз в скрипте, и запрашивать у демона уже расшифрованные данные по тому же ключу или ID сессии? С чего вы взяли, что это решение более медленное?
4. Зависит от проекта. Некоторые делают исходя из возможности хостинга, некоторые — с расчетом callocation — то есть серваки стоят собственные. Есть проекты, требующие максимальной масштабируемости, есть — не требующие.
5.(про задержки) увеличте количество демонов, распределите нагрузку фиксированно и задержки будут более чем приемлемыми.
P.S. сколько можно повторять: я не настаиваю на конкретном решении. лишь предлагаю альтернативу, которая будет приемлема конечно же только в ограниченном количестве вариантов.
Так а я что, разве настаиваю на конкретном решении? ))) Конечно надо расматривать альтернативы, взвешивать и тестировать. Я вроде об этом в основном и говорю.
>> Low-level программирования в статье, кстати, не было — использовали готовую библиотеку, так что тут с поддержкой всё ок.
Готовую, но чужую. Mcrypt поставляется вместе с PHP. Здесь заюзана чужая разработка(Ботан). В разных случаях это может дать разные нюансы.
Кроме того, здесь описана конкретная проблема и обсуждается конкретное решение. А если таких проблем и решений будет еще несколько? Проект обрастет библиотеками и чужими фреймворками… А вот имея уже готовый шаблонный демон, на него можно много чего повесить, учитывая, что он наботает бэкэндом, то есть работает где-то внутри системы на отдельных серверах, в конфигурации которых можно по-своему оптимизировать процессы.
Приходим к тому же, что вы и написали — надо садиться, рассматривать, думать, решать в каждом случае. Но при этом для начала полезно вообще видеть эти нюансы. Если люди о них не знают, это же не значит, что их нет. Это только значит, что они вероятно столкнутся с ними позже, возможно в не очень удобный момент )))
У меня на фряхе плевался чужой памятью только в путь. В итоге косяк с адресацией был мой собственный и был обнаружен, но выплевывал чужую память в сокет уже не мой код. Там еще были некоторые решения, построенные на шаред мемори, возможно это одна из причин доступности чужой памяти на чтение «не нулей».
В общем сути это не меняет: я не говорил, что это обязательно, что явление частое и все такое. Просто предупредил, что такие проблемы тоже возможны и привел навскидку один из вариантов решения. Это так, между делом, к основной теме разговора конечно не относится.
Есть множество нюансов как у варианта с демоном, так и у текущего варианта.
В каждом конкретном случае нужно эти нюансы рассматривать и уже потом решать.
Навскидку:
1. В крупных проектах заказчики любят в первую очередь масштабируемость. Им проще докупить серверов в стойки, чем оптимизировать отдельные куски. Особенно, если эти куски требуют такой низкоуровневой оптимизации. Иными словами демон, работающий с тем же стандартным mcrypt, но оптимизирующий само количество дешифраций, будет предпочтительнее в ряде случаев.
2. Демоны эти тоже можно сделать масштабируемыми. То есть серверов под них можно плодить сколько угодно и распределять между ними нагрузку.
3. Задержки канала связи с демоном, даже если он будет физически на другой машине, не всегда являются узким местом, даже если это кажется очевидным на первый взгляд. При правильном подходе для клиента просто страница будет генериться на доли секунды дольше. Во многих случаях это вполне приемлемо. Но серваки при этом не будут потеть от перегрузок. То есть упомянутое вами доп. время уже не связано напрямую с загрузкой процессоров. Иными словами общение с демоном мало чем будет отличаться от общения с основной БД например.
4. Библиотеку, напрямую прилинкованную к тому же PHP, нужно будет прикомпилировать к каждому новому вводимому в строй серверу. Кроме того, нужны будут люди, обслуживающие ее, то есть люди, разбирающиеся в этой низкоуровневой оптимизации и работе с инструкциями процессоров. Что получает заказчик после сдачи проекта и смены комманды разработчиков к примеру? Геморрой. Вот что он получает.
Так что тут еще вопрос, какой из вариантов считать костылями. Если серверов один-два, то вариант с бибилиотекой вполне прокатит — он действительно имеет более прямое использование и минимальный latency. Но судя по скудному описанию проекта в посте, проектик здесь достаточно крупный, чтобы дать приоритет масштабируемости.
Как-то так.
P.S. С метеозондами и просто шариками с гелием то же самое — они лопаются сами, достигая определенной высоты — их просто разрывает изнутри в разреженной среде.
http-процесс может при нарушениях, вызванных к примеру атакой переполнения буффера, тупо выплюнуть во внешний сокет произвольный кусок памяти машины. Я с этим сталкивался раньше. Это так или иначе связано с человеческим фактором, то есть с косяками программистов, и подобные косяки со временем правятся, и они редкие, но тем не менее так бывает. Так вот. Есть вероятность, что туда могут попасть хранящиеся там дешифрованные данные в plain-виде.
Конечно, тут все зависит от конфигурации системы — демон можно выкинуть на отдельный сервак и все такое. Правда со всеми вытекающими задержками. Но во многих случаях они приемлемы, да и при распределении нагрузки(балансировке) локальный кеш каждого сервака особого смысла уже не имеет.
Совершенно верно )
Это я к вашему:
>> а ведь friq написал ровно то же самое, другими словами. Интересно, почему у меня это не осозналось при первом прочтении?
Мне показалось, про волынку более короткое и веселое объяснение. Я ж не знал, что вы про нее так мало знаете ))))
Да и вообще. Если кто-то потом это все будет читать, и не поймет с первого и второго раза, зато поймет с третьего или четвертого. Так что эти альтернативные объяснения вполне могут быть полезны )
А так я бы тоже сделал демон, который бы не просто делал постоянный декрипт одних и тех же данных, а к примеру хранил в памяти кеш расшифрованных данных, расшифровав их единожды в момент логина пользователя, и отдающий нужную их часть по запросу с ключем шифрования либо по идентификатору сессии.
Так оптимальнее.
Для особо паранойных безопасников есть вариант перешифровывать данные в памяти чем-то более простым типа RC4 — это защита на случай атак переполнения буфферов, когда при косяках в настройках серваков в HTTP-сокеты могут вываливаться дампы произвольных кусков памяти.
Музыкальный инструмент такой. Обычно принято его видеть в руках у шотландцев в клетчатых юбках(килтах).
Суть инструмента — буфферный кожаный мешок, прижимаемый локтем к телу. Есть трубка, через которую в мешок нагнетается воздух(вход), есть одна или несколько звукообразующих трубок(выходы). Для простоты примем один выход. В выходе встроена пищалка и дырки или поршни, изменяющие тон звука.
Постоянная скорость(давление) на выходе регулируется прижимом локтя, воздух поступает непостоянно — игроку нужны перерывы как минимум на вдох.
Однако за счет мешка-буффера при непостоянном и нерегулярном пополнении запаса воздуха волынка может играть условно вечно и при этом полное легато(переход между нотами без прерывания звука).
Так же есть электроволынки(с компрессором) и универсальные интрументы типа «человек-оркестр», где воздух может нагнетаться в мешок любым способом, например ножным насосом типа «лягушка».
Вот здесь мы имеем ровно то же самое — хоть ветряки наверху качают воздух в мешок непостоянно, за счет глубины и постоянного давления из мешка по отдельному каналу на турбину подается постоянный сглаженный поток воздуха. То есть от ветряка прямой отвод на турбину/генератор в общем-то и не нужен вовсе. Система стабилизирована. Отчасти это даже похоже на водонапорную башню — там принцип по сути тот же — держать на выходе константное давление.
Итого: тождественность законов физики во всей красе — давление в водонапорной башне, в этих мешках на 600-метровой глубине, напряжение в электросети — одного поля ягоды.
То есть спонтанно там судам и особенно лодкам делать как бы нечего )
Да. В этом и есть часть идеи. Давление должны держать только сами стенки мешка — материал устойчивый к сплющиванию. «На разрыв» же нагрузка малая.
Если вы не поняли — ваш аккумулятор не собираются использовать, чтобы тупо выкачать из него накопленную вами энергию. Его будут использовать для сглаживания скачков в потреблении на районе например(ага, типа как LC-фильтры в блоках питания). Хотя частично по вашему желанию могут и выкачивать(за все те же льготы или взаимозачетом к вашим счетам за свет), если к примеру ваш ежедневный путь на работу и домой во многом состоит из стояния в пробках — при таком режиме работы двигла у вас все-равно с генератора избыток энергии идет.
Во-вторых. Да, износ будет больше при таких режимах. Однако зимой вы зато гарантированно заведетесь даже с изношенного аккумулятора, ибо простояв ночь на подключении к сети, он будет «прогрет» на момент старта двигла. На «крутануть немного стартер» хватит по-любому. А в обычном режиме замерз бы нафиг за ночь и все. Совсем хорошо, когда точки подключения к системе есть и на работе и дома.
Во-третьих это вообще дело добровольное. Не хочешь — не участвуй.
Кстати аппаратура в точке подключения вам так же подскажет приблизительную степень износа по графикам заряда/разряда за ночь, и соответственно вы будете точно знать, когда аккум пора менять. Сможете принять решение например перед дальней поездкой не наобум, как все делают обычно, а на основании вполне осязаемых цифр.
Понятное дело, что аппаратура в точках подключения должна состоять не тупо из двух клемм и амперметра. Если грамотно все реализовать, можно дойти вплоть до меток аккумуляторов(узнавание) и центральной БД, и многие вещи(от начислений бонусов до ведения пожизненной статистики состояния аккумулятора) будут делаться автоматически, даже если вы «воткнетесь» в точку в соседнем регионе.
Еще навскидку пришла мысль об льготной утилизации «меченного» аккумулятора. Чем не повод для поощрения? Когда не тупо выкинул, загаживая природу, а сдал в утиль, да еще и бонус за это вернул.
В общем, при желании можно реализовать немалое количество плюсов в этом методе.
Тут засада может быть в технических ограничениях. Дело в том, что это расширение от Яндекса — оно «продвинутое». То есть оно использует дополнительную скомпилированную библиотеку(ака DLL) для некоторых своих функций. И эти бинарники оно содержит для каждой поддерживаемой платформы свои.
Сами эти бинарники нужны для более полноценного контроля браузера, например чтобы перехватить создание новой вкладки. Я про эти методы даже где-то в документации гугля читал.
Собственно именно поэтому юзера так сильно хотят например полноценный букмарк-менеджер, но при этом никто не может написать таковой как стандартное расширение — в доступном для стандартных расширений API тупо не хватает функционала. А вот за счет плагинной библиотеки это сделать можно, но будет некроссплатформенно в большинстве случаев — ибо мало кто, написав либу под винду, будет писать порты на мак и линукс, и vise versa.
А Яндекс вот написал — то есть расширение работает в виндовс, макоси и линуксе. Но к сожалению не синхронизируется — как минимум кроссплатформно. Не знаю, синхронятся ли у хрома на одной платформе данные и настройкеи расширений или нет. Выделенной синхронизации у данного расширения тоже нет.
chrome.google.com/webstore/detail/pchfckkccldkbclgdepkaonamkignanh
Оно как раз заменяет полностью стандартный интерфейс новой вкладки, и единственный его недостаток — нет этого списка последних закрытых вкладок.
Это компенсируется соответствующим разделом в главном меню на маке, либо в контекстном меню кнопки панели задач на виндовс. Но там в обоих случаях список коротковат. А данное расширение(секси анду таб) полезно как минимум тем, что ограничений в этом списке условно нет.
Удобство здесь в том, что он делает из гугль-калькулятора некое подобие коммандной строки — в ней запоминаются все введенные расчеты(история), по клавише «вверх» можно выбрать что-либо, введеное ранее и т.п. И это доступно в виде кнопки на тулбаре — не нужны лишние действия по созданию новой вкладки, переключению между вкладками с данными(прайслистом магазина) и вкладкой с гуглем. Ну и т.п. Просто удобный ГУЙ к калькулятору гугля в общем…
И еще там можно поставить доп.плагин для возможности назначить хоткей вызова и локальный URL поисковой машины. google.ru вместо google.com например — если охота, чтоб результаты выдавались на русском.
Пользую постоянно для расчетов вида:
1133 eur in rur
(780.67+37.82) eur in rur
((705*2)-1000)*0.3
(0x0C*12) in hex
0xFCF09512 in decimal
12mm in inches
0.37 inches in mm
и т.п.
Но в основном конечно для переводов валют, рассчета таможенных пошлин и т.п. при заказе посылок из-за бугра.