Я немного в другом аспекте сравнил эти два высказывания. Всяческие наставления, отсылающие к формальным причинам (в первом случае — «чтобы не было застоя», «чтобы получить новый опыт», «так вы выглядите более привлекательным в глазах следующего работодателя», «вы узнаете себе цену» и т.д., а во втором «в щетке копятся микробы», «щетка стирается и становится менее эффективной») годятся для зубной щетки, но выглядят абсурдом, будучи примененными к судьбе человека.
Была одна зубная щетка, которой я пользовался несколько лет. Сначала ею чистил зубы, а потом она помогала мне наносить крем на обувь в районе каблука и кромки подошвы.
Я не имел ввиду, что именно боты — это причина развития кризиса (про боты я написал, потому что был такой факт, и тем, кто не знал, это будет интересно). Я написал, что чрезмерно эффективные механизмы обеспечения сделок послужили одной из причин взрывного развития ситуации (а вообще причин было много и нет ни одной, которая была единственной и решающей, именно цепочка событий привела к проблеме). Не хочется в это вдаваться, так как не хочется уводить разговор от темы.
Я написал статью исходя из нашего многолетнего опыта работы на разных рынках по всему миру. Можно придраться к любому слову из того, что я написал, потому что, как вы понимаете, любые обобщения всегда страдают неточностью. Конечно же, совсем без доверия невозможно ничего выстроить нигде. Безусловно, не все решается в судах. Конечно же, японская экономика совсем не идеальна. Но отличие, которое я описал, существует, для меня оно так же явственно, как отличие между чаем и мороженым. Мы уже имели опыт множества тяжб в США (не инициированных нами), не говоря уже о количестве потенциальных тяжб (я думаю, эта цифра исчисляется сотнями), которых нам удалось избежать путем переговоров. При том, что у нас не было ни одной судебной тяжбы в Европе, и очень редко бывают случаи, когда кто-то нам угрожает судом. Очень трудно сравнить поведение среднего партнера в США и в Азии — совершенно разные ментальности. Даже близко не стоят процессы проведения переговоров и наведения мостов, а также процесс взаимодействия после этого.
Что касается термина «кризис», то большинство экспертов сходятся на том, что нынешней жизнью нам придется жить долго. Продолжать называть это «кризисом» — это жить во вчерашнем дне. Это новая реальность и она такова надолго.
Совершенно верно. По этой же причине меня воротит от карьерных советов типа «нужно менять место работы раз в три года» и т.д. Звучит примерно как «надо менять зубную щетку раз в два месяца».
Что как бы слегка опровергает слова о неплатежеспособности Linux-клиентов и бесперспективности Linux-рынка, не находите? ;)
Линукс-серверов, а не клиентов. Несложно догадаться, что в подавляющем большинстве случаев продукт лицензируется для реализации серверных решений на корпоративном рынке. Это вполне живой рынок.
Теоретически возможен расклад, при котором может появиться потребность в Linux-версии Lingvo. Но пока, к сожалению, мы вообще никаких обещаний дать не можем. Если бы я имел возможность показать вам цифры и факты, у вас не возникло бы вопросов, я думаю. Но, к сожалению, нет такой возможности. Поэтому, просто поверьте на слово.
Ну так у нас и FineReader Engine под Linux неплохо продается. Все продукты, которые Вы указали, объединяет одно: у них 97% кода — переносимое технологическое ядро, и 3% кода — оболочка. К сожалению, для OCR продукта, который от нас ожидает Linux-аудитория, такой расклад не покатит. А для желающих просто командно-строчно конвертнуть файлы в Linux есть вполне себе недорогое решение (правда, пока продается только в Европе).
В Канаду давно мечтаю съездить, был только пару раз, и то давно.
Я бы тоже очень хотел верить, что для Linux можно делать коммерческие приложения и их будут покупать. Честно. Очень хотел бы. Но все результаты всех наших исследований пока, к сожалению, показывают обратное. Если у вас есть другая информация — пишите в личку, встретимся, расскажете.
Затраты на изготовление оболочки под Linux, действительно, существенные. Несмотря на это мы были бы рады освоить новую платформу, если бы у продукта были бы хоть какие-то коммерческие перспективы. У нас и внутри компании любителей Linux достаточно много. Но вот они и сами признаются, что ни одной купленной программы на их линуксовых компьютерах нет. А у вас есть?
По поводу озвучивания: вы же не будете учить слова по тому, как их озвучивает автомат? В Lingvo озвучивание слов выполнено профессиональными дикторами на родном языке, причем не только для английского, но и для немецкого и испанского.
По поводу iPhone я ответил ниже. Про остальное пока говорить рано.
Мы уже анонсировали, что версия Lingvo для iPhone находится в разработке (http://forum.lingvo.ru/actualthread.aspx?tid=98691, например). Ждем вот-вот уже. Самому нужна позарез.
Это первая версия Lingvo для Mac, у нас есть интересные идеи в развитие. Но уже сейчас есть несколько важных причин, которые не позволяют использовать Dictionary.app для словарей Lingvo. Первая — озвучивание слов. Для множества наших пользователей, особенно свитчеров, это must. Вторая — Dictionary.app создает не вполне корректный словник. Например, если вы наберете буквы «сердц» в строке поиска, то вам выдадутся варианты сердца, сердцами, сердцах, и т.д. Это затрудняет поиск нужных слов. По этой же причине встроенным словарем не очень удобно пользоваться в режиме «чтения словаря», а это любимое занятие многих наших пользователей — просто листать словарь и читать про интересные слова.
В третьих — в морфологии Dictionary опирается на довольно куцый словарь для русского языка, который есть в Mac OS. Если вы используете спеллер в Cocoa-приложениях, то наверняка замечали, что он не знает многих русских слов и словоформ. Это сделает поиск многих слов в словаре невозможным. Можно еще перечислять удобства Lingvo, к которым наши пользователи привыкли, и которых нет в Dictionary.app.
Но самая главная причина все же состоит в том, что мы хотим дальше развивать этот продукт, и заодно привязать его к уже существующей инфраструктуре Lingvo. А для этого надо иметь свою оболочку, никуда не денешься.
Технологические библиотеки редко когда делаются только под серверную платформу. Как раз наоборот: для сервера технологию проще упаковать в сервис. А для клиента как раз удобнее библиотека. Это если в рамках этой темы рассуждать. А если в целом, то, опять же, продуктизация внутри компании по возможности должна учитывать наличие в мире такой штуки, как Windows.
Позвольте встрять. Не по поводу темы конкретной статьи. Она описывает частный случай быстрого решения проблемы совместимости с 64-битным кодом. Нормальная техника, может помочь в конкретной ситуации, когда почему-то (неважно почему) существующий код оказалось не просто перенести на 64-бита.
Я по поводу кросс-платформенности вообще. Для коммерческих продуктов критична не только работоспособность, но и конкурентоспособность. В частности, для библиотек очень часто важна скорость работы. Для победы над конкурентами по этому параметру приходится применять всяческие уловки:
— ассемблер (редко, осторожно, только если реально помогает).
— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
— оптимизация файловых операций (тоже по-разному работает на разных платформах)
— компиляторные оптимизации и оптимизация кода под конкретный компилятор(работают ОЧЕНЬ по-разному для разных платформ, а на кросс-платформенном GCC до сих пор работают нестабильно).
— процессорные оптимизации (оптимизация под конкретный процессор).
— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом. От этих действий код может стать сильно не-кроссплатформенным. В этом нет ничего страшного: вместо того, чтобы заставлять 50 человек писать кросс-платформенный код, часто имеет смысл сфокусировать их на качестве работы кода на одной, основной платформе, а еще двух людей потом попросить перенести этот код на другие платформы. Это дешевле и эффективнее с точки зрения достижения результата.
И еще: алгоритм распознавания очень непростой. Наверное, как-нибудь стоит рассказать о нем поподробнее на Хабре. Это не математика. Это скорее искусственный интеллект.
Не за что :) В других странах мы пока с такими проблемами не сталкивались, поэтому говорить особенно не о чем. Была попытка одного нашего конкурента в Европе использовать лазейку в виде патента на полезную модель для того, чтобы сделать атакующий патент в области ПО, но она благополучно провалилась. Инициированное (не нами) судебное разбирательство отменило этот патент.
Адвокат по вашему поручению имеет право в рамках защиты собирать информацию, консультироваться с различными людьми. Все это подпадает под тайну переписки. Важно, чтобы во всех этих действиях участвовал адвокат, который имеет лицензию и который в данный момент является вашим официальным патентым поверенным. На практике это выглядит таким образом: ответчиком по делу будет ваш американский офис, но ему, очевидно, потребуется ваша помощь (если вы расположены в России). Понятно, что вся переписка будет между сотрудниками американского офиса, их адвокатом и, с точки зрения суда, посторонними людьми в лице российских сотрудников. Для того, чтобы не случилось накладок, полезно предварить subject таких писем фразой типа: Attorney Privileged Communication.
Я написал статью исходя из нашего многолетнего опыта работы на разных рынках по всему миру. Можно придраться к любому слову из того, что я написал, потому что, как вы понимаете, любые обобщения всегда страдают неточностью. Конечно же, совсем без доверия невозможно ничего выстроить нигде. Безусловно, не все решается в судах. Конечно же, японская экономика совсем не идеальна. Но отличие, которое я описал, существует, для меня оно так же явственно, как отличие между чаем и мороженым. Мы уже имели опыт множества тяжб в США (не инициированных нами), не говоря уже о количестве потенциальных тяжб (я думаю, эта цифра исчисляется сотнями), которых нам удалось избежать путем переговоров. При том, что у нас не было ни одной судебной тяжбы в Европе, и очень редко бывают случаи, когда кто-то нам угрожает судом. Очень трудно сравнить поведение среднего партнера в США и в Азии — совершенно разные ментальности. Даже близко не стоят процессы проведения переговоров и наведения мостов, а также процесс взаимодействия после этого.
Что касается термина «кризис», то большинство экспертов сходятся на том, что нынешней жизнью нам придется жить долго. Продолжать называть это «кризисом» — это жить во вчерашнем дне. Это новая реальность и она такова надолго.
Линукс-серверов, а не клиентов. Несложно догадаться, что в подавляющем большинстве случаев продукт лицензируется для реализации серверных решений на корпоративном рынке. Это вполне живой рынок.
Теоретически возможен расклад, при котором может появиться потребность в Linux-версии Lingvo. Но пока, к сожалению, мы вообще никаких обещаний дать не можем. Если бы я имел возможность показать вам цифры и факты, у вас не возникло бы вопросов, я думаю. Но, к сожалению, нет такой возможности. Поэтому, просто поверьте на слово.
В Канаду давно мечтаю съездить, был только пару раз, и то давно.
Более того, уже почти год на рынке есть FineReader for Mac: www.abbyy.com/finereader_for_mac/
Затраты на изготовление оболочки под Linux, действительно, существенные. Несмотря на это мы были бы рады освоить новую платформу, если бы у продукта были бы хоть какие-то коммерческие перспективы. У нас и внутри компании любителей Linux достаточно много. Но вот они и сами признаются, что ни одной купленной программы на их линуксовых компьютерах нет. А у вас есть?
По поводу iPhone я ответил ниже. Про остальное пока говорить рано.
В третьих — в морфологии Dictionary опирается на довольно куцый словарь для русского языка, который есть в Mac OS. Если вы используете спеллер в Cocoa-приложениях, то наверняка замечали, что он не знает многих русских слов и словоформ. Это сделает поиск многих слов в словаре невозможным. Можно еще перечислять удобства Lingvo, к которым наши пользователи привыкли, и которых нет в Dictionary.app.
Но самая главная причина все же состоит в том, что мы хотим дальше развивать этот продукт, и заодно привязать его к уже существующей инфраструктуре Lingvo. А для этого надо иметь свою оболочку, никуда не денешься.
Я по поводу кросс-платформенности вообще. Для коммерческих продуктов критична не только работоспособность, но и конкурентоспособность. В частности, для библиотек очень часто важна скорость работы. Для победы над конкурентами по этому параметру приходится применять всяческие уловки:
— ассемблер (редко, осторожно, только если реально помогает).
— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
— оптимизация файловых операций (тоже по-разному работает на разных платформах)
— компиляторные оптимизации и оптимизация кода под конкретный компилятор(работают ОЧЕНЬ по-разному для разных платформ, а на кросс-платформенном GCC до сих пор работают нестабильно).
— процессорные оптимизации (оптимизация под конкретный процессор).
— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом. От этих действий код может стать сильно не-кроссплатформенным. В этом нет ничего страшного: вместо того, чтобы заставлять 50 человек писать кросс-платформенный код, часто имеет смысл сфокусировать их на качестве работы кода на одной, основной платформе, а еще двух людей потом попросить перенести этот код на другие платформы. Это дешевле и эффективнее с точки зрения достижения результата.
И еще: алгоритм распознавания очень непростой. Наверное, как-нибудь стоит рассказать о нем поподробнее на Хабре. Это не математика. Это скорее искусственный интеллект.