А тогда начнется допиливание, встраивание заплаток на основе «старья, которое развивалось-развивалось» и т.д. И получим в итоге нормальную полноценную ОСь, только с меньшим функционалом, потому-что она вынуждена догонять убежавших вперед «старичков».
Насчет «никто не мешает развивать не свою» — недавно на хабре была хорошая статья про бодание уже более полугода насчет отмены новшеств в функции memcpy из glibc.
Можно конечно сделать свою ветку существующей библиотеки, но тогда надо обязательно поставлять ее со своими разработками. А если у клиента уже стоит и используется такая библиотека из родной ветки — как быть? Ведь есть риск больших переделок под себя. А дорабатывать официальными путями — может оказаться слишком долго для вас и вашего проекта.
Брал у них два телефона, Нокия Е72 и Сонэрих Иксперия 8 — оба с ростэстовскими наклейками и бумажками. Конечно это все легко лепится, но тогда как проверять? И кому вообще доверять можно?
Ощущение, что продажи продукции Apple в России происходят по принципу «покупатель ищет товар» а не «товар ищет покупателя». Мы им настолько неинтересны?
Да. Нашел на Плеер.ру. Они вроде серым товаром не торгуют. Странно, что в таких массовых сетях, как Связной и Евросеть iPad отсутствует в продаже, хотя Гэлэкси есть, Роверпад, ViewSonic ViewPad присутствуют, а iPad они как-то игнорируют. Поэтому и решил, что iPad-ы до сих пор только «серые» ввозятся.
Возможная причина такого игнора — работа маркетологов других компаний. Apple продвижением в России не занимается, а тот-же Гэлэкси по ящику рекламу крутит. Наверное и с продавцами работают, чтобы их товар на прилавке был.
При равной цене большая диагональ в данном случае — преимущество.
Если положить их рядом и предложить человеку выбор, уверен, большинство возьмут 10ку. С учетом, что остальные параметры будут примерно одинаковы. Но похоже у iPad'a еще и время работы больше. Так что проигрыш налицо. Выигрыш только в том, что iPad-ы вроде вбелую не поставляются до сих пор. Те. на витрине магазина народ их не видит, а видит Гэлэкси, да теперь этот HTC. У Гэлэкси он выигрывает. А если рядом на витрине появятся iPad-ы за те-же деньги — трындец.
Ну раз есть емкостные стилусы, что мешает найти и купить такой и таскать в кармане?
Тем более, судя по фотке, и для HTC стилус не втыкается в корпус, толстый карманный отдельно носимый вариант.
10-дюймовый iPad и 7-дюймовый HTC имеют право одинаково стоить?
Уверен, если Apple сделает мини-iPad с 7ю дюймами, он и стоить будет дешевле. Кто тогда вообще будет смотреть на эти HTC и Гэлэкси-табы?
Неконкурентная на мой взгляд цена. Очень неконкурентная.
Движок на сях мне как-то ближе по духу :)
Но что больше всего подкупает в Hyper Estraier — это то, что я на беглое изучение, установку, тестирование потратил ужасно мало времени. Убедился в приемлемости полученного результата и уже готов внедрять в работу. Возможно через неделю он уже будет стоять и работать.
Такого быстрого «въезда» у меня не было ни с одним из рассматриваемых ранее поисковиков — ht/Dig, Lucene, Sphinx.
Вообще стиль «упаковки» продуктов и оформления документации ребятами из FalLabs очень подкупает. Просто, функционально, понятно. Смотрю на свой пост и понимаю, что он пустой. но так получается, что особо описывать-разжевывать то и нечего, любой желающий может сам взять, быстро поставить и попробовать.
А в какой движок она интегрирована?
Демон здесь — один из вариантов. Можно и напрямую работать с индексом. Просто демон дает несколько лучший результат скорости поиска.
На самом деле технология одна и та-же — hash/b-tree в различных вариантах. Ничего более быстрого и удобного вроде не придумали с тех пор. Вопрос скорее в реализации.
Думаю и динамический контент можно хранить распределенно. Современный DHTML на JavaScript может обеспечить вполне приемлемый функционал. Страница будет собирать данные с пиров и окончательно монтироваться на клиентской стороне.
В общем я считаю, что современные технологии это позволяют. Дело за проработкой идеологии, схемы таких механизмов, и самое главное — их реализацией.
По-моему ADABAS на IBM-360 была иерархическая. Интересно, сейчас есть что-то подобное?
Есть еще сетевая модель БД. Комерческая реализация была сделана Raima corp. (если правильно написал) — dbVista звали ту БД. Вроде она и сейчас живет. У меня где-то лежат сырцы ее опенсорсного варианта — db-Star (db-linux). Одно время они были в инете, но сейчас вычистили.
Сделал тест с msiz=64m — уравнял размеры кэша с дефолтным MemcacheDB
Результат:
— запись — 25 мин 43 сек
— чтение — 12 мин 26 сек
Т.е. всеравно скорости выше. Но оперативки он сожрал 400 Mb — в два раза больше.
Поэтому по оперативке — проигрыш, по скорости и размеру БД на диске — выигрыш.
Наверняка выигрыш по скорости и из-за более компактного хранилища — меньше дисковых операций.
В столь большом времени общего «забега» судя по всему была виновата возросшая дневная нагрузка на сервер. К сожалению абсолютно чистого сервера у меня не было.
В утренние часы я получал лучшие по времени результаты, ближе к вечеру — худшие.
Поэтому самые первые тесты я повторил несколько раз, в разной очередности и в разное время суток. А парный забег повторять не стал, поскольку тут они работали в одинаковых условиях.
Запустил с кэшем 64 мега — посмотрим :)
У меня не стоит задача расхвалить Kyoto Tycoon. Подвернулся случай пощупать этот софт, результаты показались интересными, решил поделиться. Если бы он проиграл MemcacheDB, я бы об этом тоже написал. Честное пионерское!
Сообщения были. Функция сохранения данных возвращала код ошибки. Просто когда я запустил несколько тестов пакетом — отправил свой лог в /dev/null, чтобы диск не засорять. На последнем тесте чтения увидел ошибку, что считано меньше записей, чем сохранено. Прогнал еще пару тестов, уже с сохранением логов, и обнаружил причину.
В процессе работы Kyoto Tycoon постоянно сбрасывает обновления на диск. По окончании записи я рестартовал сервер и выполнял контрольное чтение — потерь данных не было. Если вы просмотрели все результаты тестов, я запускал и вариант с дефолтными настройками, которые достаточно скромны, говорить там о кэше памяти нельзя, и всеравно результат ухудшился не сильно и был заметно лучше, чем у MemcacheDB.
Можно конечно сделать свою ветку существующей библиотеки, но тогда надо обязательно поставлять ее со своими разработками. А если у клиента уже стоит и используется такая библиотека из родной ветки — как быть? Ведь есть риск больших переделок под себя. А дорабатывать официальными путями — может оказаться слишком долго для вас и вашего проекта.
Возможная причина такого игнора — работа маркетологов других компаний. Apple продвижением в России не занимается, а тот-же Гэлэкси по ящику рекламу крутит. Наверное и с продавцами работают, чтобы их товар на прилавке был.
Если положить их рядом и предложить человеку выбор, уверен, большинство возьмут 10ку. С учетом, что остальные параметры будут примерно одинаковы. Но похоже у iPad'a еще и время работы больше. Так что проигрыш налицо. Выигрыш только в том, что iPad-ы вроде вбелую не поставляются до сих пор. Те. на витрине магазина народ их не видит, а видит Гэлэкси, да теперь этот HTC. У Гэлэкси он выигрывает. А если рядом на витрине появятся iPad-ы за те-же деньги — трындец.
Тем более, судя по фотке, и для HTC стилус не втыкается в корпус, толстый карманный отдельно носимый вариант.
Уверен, если Apple сделает мини-iPad с 7ю дюймами, он и стоить будет дешевле. Кто тогда вообще будет смотреть на эти HTC и Гэлэкси-табы?
Неконкурентная на мой взгляд цена. Очень неконкурентная.
Но что больше всего подкупает в Hyper Estraier — это то, что я на беглое изучение, установку, тестирование потратил ужасно мало времени. Убедился в приемлемости полученного результата и уже готов внедрять в работу. Возможно через неделю он уже будет стоять и работать.
Такого быстрого «въезда» у меня не было ни с одним из рассматриваемых ранее поисковиков — ht/Dig, Lucene, Sphinx.
Вообще стиль «упаковки» продуктов и оформления документации ребятами из FalLabs очень подкупает. Просто, функционально, понятно. Смотрю на свой пост и понимаю, что он пустой. но так получается, что особо описывать-разжевывать то и нечего, любой желающий может сам взять, быстро поставить и попробовать.
Демон здесь — один из вариантов. Можно и напрямую работать с индексом. Просто демон дает несколько лучший результат скорости поиска.
И за ссылки на материалы по теме.
В общем я считаю, что современные технологии это позволяют. Дело за проработкой идеологии, схемы таких механизмов, и самое главное — их реализацией.
Есть еще сетевая модель БД. Комерческая реализация была сделана Raima corp. (если правильно написал) — dbVista звали ту БД. Вроде она и сейчас живет. У меня где-то лежат сырцы ее опенсорсного варианта — db-Star (db-linux). Одно время они были в инете, но сейчас вычистили.
Результат:
— запись — 25 мин 43 сек
— чтение — 12 мин 26 сек
Т.е. всеравно скорости выше. Но оперативки он сожрал 400 Mb — в два раза больше.
Поэтому по оперативке — проигрыш, по скорости и размеру БД на диске — выигрыш.
Наверняка выигрыш по скорости и из-за более компактного хранилища — меньше дисковых операций.
В утренние часы я получал лучшие по времени результаты, ближе к вечеру — худшие.
Поэтому самые первые тесты я повторил несколько раз, в разной очередности и в разное время суток. А парный забег повторять не стал, поскольку тут они работали в одинаковых условиях.
У меня не стоит задача расхвалить Kyoto Tycoon. Подвернулся случай пощупать этот софт, результаты показались интересными, решил поделиться. Если бы он проиграл MemcacheDB, я бы об этом тоже написал. Честное пионерское!
Вот еще в копилочку, уже из нынешнего :)