Компания Oracle перевела популярную встраиваемую БД Berkeley DB на лицензию AGPLv3, которая применяется начиная с выпусков 6.0 / 12c. Изначально проект поставлялся под копилефт лицензией Sleepycat Public License, признанной фондом СПО полностью совместимой с GPL, в том числе с лицензией GPLv2. Разработчики проекта Debian выразили опасение (http://permalink.gmane.org/gmane.linux.debian.devel.legal/35034), что перевод Berkeley DB на более ограниченную лицензию AGPLv3, совместимую только с GPLv3, приведёт к лицензионному конфликту с приложениями, поставляемыми под лицензией GPLv2. В качестве одного из предложенных решений упоминается поставка Berkeley DB 5.3 в следующем и возможно всех остальных выпусках Debian, переход на совместимые с Berkeley DB альтернативы или проведение работы по перелицензированию downstream-компонентов.
Особенностью лицензии AGPLv3 является введение дополнительных ограничений для приложений, обеспечивающих функционирование сетевых сервисов. При использовании AGPL-компонентов при обеспечении работы сервиса, разработчик обязан открыть исходный код модифицированных AGPL-компонентов. С учётом того, что Berkeley DB поставляется в форме библиотеки, под данное требование подпадают и приложения, связываемые с библиотекой. Лицензия Sleepycat напоминает GPL и треует у разработчика предоставления данных о получении полных исходных текстов как библиотеки Berkeley DB, так и построенных на её основе приложений, но не препятствует использованию для создания закрытых web-сервисов. Таким образом, введя требования по открытию кода web-сервисов, использующих Berkeley DB, компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии.Berkeley DB входит в числе базовых библиотек, от которых зависят многие пакеты. В связи с этим поставлен вопрос, допустима ли поставка базовых библиотек под AGPLv3, так как связывание с AGPLv3-библиотекой приведёт к распространению лицензии AGPLv3 на все использующие данную библиотеку пакеты. С другой стороны, компоненты под AGPLv3 являются свободным ПО и их включение в число базовых компонентов полностью соответствует правилам проекта Debian.
По мнению (http://permalink.gmane.org/gmane.linux.debian.devel.legal/35050) Бредли Куна (Bradley M. Kuhn), одного из авторов AGPL, занимающего пост исполнительного директора правозащитной организации Software Freedom Conservancy (SFC), несмотря на то, что поднятый вопрос вызывает обоснованный повод для беспокойства, поставка новой версии Berkeley DB в дистрибутиве не является непреодолимой проблемой и потенциальный лицензионный конфликт может быть сглажен. В качестве аналога указывается на то, что обеспечение лицензионной совместимости с компонентами GPLv2 является более трудной задачей, чем с компонентами Apache, тем не менее в дистрибутиве удаётся добиться совместной поставки компонентов под копилефт и либеральными лицензиями.
В случае AGPL, пересмотр политики распространения web-приложений главным образом ложится на плечи разработчиков сервисов, использующих компоненты из состава дистрибутива. Проблемы также могут возникнуть у поставщиков решений на базе Debian.
В частности, разработчики и проекты, которые не пожелают выполнить условия AGPL, будут вынуждены рассмотреть возможность миграции на альтернативные системы, такие как LMDB (http://symas.com/mdb/).
URL: http://www.infoworld.com/d/open-source-software/oracle-switc...
Новость: http://www.opennet.me/opennews/art.shtml?num=37377
Что за БРЕД?
Новость звучит, вообще-то, так:«Торговцы перепакованным BDB опасаются необходимости исполнять требованиями GPLv3»
Вообще-то она звучит так:
>компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии.Что гораздо мягче вашего вброса.
Зыж
В данном случае для 3-ей стороны всё к лучшему.
Пущай проприетарщики лбами стучатся кто из них опенсорснее.
Беркелеевская база? От оракла? Под AGPLv3? Wtf? Оракл решил сказочно потроллить вообще всех и сразу чтоли? :)
> Беркелеевская база? От оракла? Под AGPLv3? Wtf? Оракл решил сказочно потроллить вообще
> всех и сразу чтоли? :)Хотят в Зал Славы Интернетов, как Ричард!
> Хотят в Зал Славы Интернетов, как Ричард!Тогда организаторы зала славы могут потроллить в ответ - засчитать как годное достижение, но к себе все-таки не вписать :)
Да, неприятная ситуация. Могут пострадать многие уважаемые проприетарные вендоры.
> уважаемые
> проприетарные/0
Мне кажется, тут стоит вспомнить о sarcasm.jpg
> Да, неприятная ситуация. Могут пострадать многие уважаемые проприетарные вендоры.ох тыж ёшкин кот
> Да - это делается единолично. Называется "накруткой голосов".Вообще-то на опеннете приняты некоторые меры для того чтобы накручивать было не то чтобы совсем невозможно, но достаточно паливно + неудобно. Думашь, ты кому-то настолько нужен? Даже мсовских ботов серьезно накручивать ломает в силу озвученных факторов.
Поэтому таки да, жмет натурально 30 разных перцев. Ну может 20-25, с учетом накруток. Просто сообщения которые вверху треда, в свежей новости - читают все. Им то и достается наибольшее зрительское внимание. А 125-й комментарий сверху - находят только самые упорные. Остальных читать флуд типа твоего спама утомляет максимум на втором десятке коментов и они это не читают. Ну и оценки там никто не жмет, т.к. не читают :). В лучшем случае - участники затянувшегося спора остаются и плюсы-минусы в небольшой количетве - от них.
>> Путен не ошибается, Столлман святой, Шаттлворт всегда прав, а GPL v.3 не обладает минусами.
> Мда. Zenitur такой zenitur.Неожиданно. Ты осуждаешь меня за мою насмешку. Ты РЕАЛЬНО соглашаешься со всеми этими высказываниями? Взрослей: сколько людей, столько и мнений, или проще говоря: не все, кто не согласны с твоим мнением, враги и их надо НИНАВИДЕТЬ.
Нет. Тебя осуждают за то, что ТЫ соглашаешься с этими высказываниями.
Oracle, конечно, какашка, но AGPL это правильное направление.P. S. Читайте рассылку Дебиана и приведённые там ссылки.
> Oracle, конечно, кaкaшка, но AGPL это правильное направление.Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам. Такой "оpакл". В полный рост.
> P. S. Читайте рассылку Дебиана и приведённые там ссылки.
Предложил местной публике прочитать анализ Бредли Кюна и _понять его? Толстячок.
> Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам. Такой "оpакл".
> В полный рост.Кругом враги©
>>Такой "оpакл". В полный рост.
> Кругом враги©Молодящаяся копирастическая - в кольце вагов. Да.
ахаха митрофанов опять разоблачает =) не устал еще покровы срывать?
> ахаха митрофанов опять разоблачает =) не устал еще покровы срывать?Сам-то, решил прикрыться, ник фейкнул. Терапия помогает - задумался, так держать.
расслабься, здесь нет тайны - у меня лишь нет желания регаться на лороподобных ресурсах :)
А регаться никто и не заставляет.
Просто если уж решил стать прославленным дятлом - не бросай с полдороги, не огорчай публику.
> расслабься, здесь нет тайны - у меня лишь нет желания регаться на
> лороподобных ресурсах :)Кстати, FAIL.
Я, :-P например, не зарегистрирован на этом ресурсе. И да, имя настоящее. И да, был идiот, который подделывал. И ты не стесняйся. Не, не моим именем подписываться. Понял-понял или повторить?
>> Фигу показалТОРГУЕШЬ agpl софтом или получаешь прибыль от веб-проекта, использующего agpl софт? — выкладывай исходники.
Где проблема-то?
Просто «теперь и в Интернете».При этом альтернатив BDB — хватает.
Если проблема ещё и в том, что нет сил лень сменить движок, то я уже не знаю, что сказать.
> Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам.А заодно еще и беркелей с их лицензией потроллили :)
> А заодно еще и беркелей с их лицензией потроллили :)Как правило, то, что содержит в названии Berkeley, весьма слабо относится к Berkeley.
Поэтому Berkeley DB распространяется отнюдь не под BSDL.
Да не, все проще: корпорасы показали лишний раз что вытереть ноги о тех кто метит в роль коврика - обычная практика :).
Это вы к тому как относился автор MySQL к коврикам из GPL ?
Фиговые из GPL коврики - жесткие и кусачие.
Поэтому тут что-то сделать может только автор, который имеет полное право в нужных местах убрать GPL и положить более мяг^W"свободный" коврик.
> Поэтому тут что-то сделать может только авторТочнее, правообладатель.
Например, если ты участвуешь в проекте под эгидой Canonical, ты автоматически утрачиваешь все права на лицензирование своего кода - этим теперь заведует лично Марк. Захочет - выпустит под GPL, а кому надо - сделает полный и эксклюзивный пермиссив.
> Это вы к тому как относился автор MySQL к коврикам из GPL ?А там ковриком сам оракл выступил походу :)
> Oracle, конечно, какашка, но AGPL это правильное направление.Что-то дорабатывать или улучшать? Зачем? Лучше сменить лицензию, чтобы создать видимость работы.
> Что-то дорабатывать или улучшать?Когда человек с ником SubGun начинает втирать про доработку и улучшение - это уже смешно.
>> Oracle, конечно, какашка, но AGPL это правильное направление.
> Что-то дорабатывать или улучшать? Зачем? Лучше сменить лицензию, чтобы создать видимость
> работы.Я про AGPL вообще, причём для программ, а не библиотек, и вообще аккуратно.
Вот так в один прекрасный день проснешься, наберешь на автомате apt-get update && apt-get upgrade и - привет, статья.PS: Впрочем, слипкаты отродясь не вызывали к себе особого доверия. Пользователи BDB в их 'свободной' реинкарнации ССЗБ.
Конечный пользователь (не распространяющий ПО в бинарном виде) никак не может нарушить xGPL, поскольку та его никоим образом не ограничивает. Ограничения касаются только тех, кто распространяет софт, поэтому засудить можно только распространителей бинарных сборок: майнтейнеров бинарных дистрибутивов и вендоров проприетарного софта.
AGPL касается и веб-сайтов (причём всех его компонентов), и любых других сервисов. Это может создавать проблему.Кстати, будет ОЧЕНЬ смешно, если на такую же лицензию переведут mysql. Это будет пыхерокапец, ВСЕХ пыхеров обяжут открыть ВЕСЬ код, и от обилия этого добра планета задохнётся и рухнет под тяжестью.
> ты всё равно не понял, что я сказал
> и совсем не потому, что я сказал что-то сложное для понимания...... а потому, что ты просто не смог сформулировать свою мысль.
> AGPL касается и веб-сайтов (причём всех его компонентов), и любых других сервисов. Это может создавать проблему.Я так полагаю, что это сугубо теоретически. По крайней мере мне пока что не попадался ни один веб-сайт, который бы в трезвом уме и здравой памяти использовал BDB & K. Ибо нахрена она там, пардон мой французский?
Это вменяемое средство для сохранения данных. Вот когда для построения страницы используется 11 sql запросов только для хранения данных - это не совсем понятно.А bdb - это очень мощная система, которая позволяет обращаться к данным, как к данным, а не с помощью языка запросов. В том же python поддержка bdb есть "из коробки", почему бы не воспользоваться, если нужны просто данные по ключу, а тот же mongodb явно избыточен (или его нет "из коробки")
Я бы использовал его для данных, если бы он был чуть попроще. А так, все эти режимы б-деревьев и прочее, когда нужно выбирать оптимальный режим, не имея на это достаточно данных - мне-то достаточно и совсем простых средств. А кому-то - недостаточно.
> же python поддержка bdb есть "из коробки", почему бы не воспользоваться,Потому что ты уже достал со своим бидоном.
это невменяемый древний капец, который нормальные люди давно заменили на qmdb/lmdb/tokyo cabinet/kyoto cabinet/и-так-далее. вообще, key/value баз — как грязи.
> это невменяемый древний капец, который нормальные люди давно заменили на qmdb/lmdb/tokyo
> cabinet/kyoto cabinet/и-так-далее. вообще, key/value баз — как грязи.Да не, на самом деле нормальная либа вполне. Правда навороченная и не особо шустрая.
ок, насчёт «невменяемый» я погорячился, конечно. либа как либа. но далеко не «единственная в своём роде».
> ок, насчёт «невменяемый» я погорячился, конечно. либа как либа. но далеко не
> «единственная в своём роде».Просто в апи есть ряд фич, прямые аналоги у "конкурентов" которым могут отсутствовать. И насколько малой кровью удастся переписать - зависит от того насколько там эти фичи апи либы использовались.
Но то что либ подобного класса в природе море - факт. По поводу чего столь резкий маневр оракла вызывает ряд вопросов.
> Кстати, будет ОЧЕНЬ смешно, если на такую же лицензию переведут mysql. Это
> будет пыхерокапец,Не будет. Старые версии нельзя перелицензировать задним числом, а вот форкнуть проект под старой лицензией - запросто (см. MariaDB).
> ВСЕХ пыхеров обяжут открыть ВЕСЬ код, и от обилия этого добра планета задохнётся и рухнет под тяжестью.
Ты забыл еще пистонщиков и рубистов - они ничем не лучше.
Чу'дную ересь несёшь. Правда-правда.Даже если оракль переведет MySQL на AGPL3/GPL3 - всегда останется MariaDB или любой другой форк от того момента, когда оно было под GPL2. Это раз.
Два - тут уже не только PHP, тут уже всё придётся открывать. Включая многие коммерческие сервисы, если уж на то пошло. Фейсбуки, гуглы, вконтакты, твиттеры и много чего еще. Это два. 70-80% сайтов с динамикой. Банковские системы (угу, MySQL есть и там). И так далее.
Поэтому даже если оракл решится на такой шаг - мне кажется, это им только боком выйдет - все сразу же соскочат на форки, и поддержку MySQL, за которую берутся деньги, можно будет сворачивать. Вряд ли они себе настолько враги.
> Чу'дную ересь несёшь. Правда-правда.А теперь посмотри на имя автора того комментария.
Еще вопросы есть?
> Поэтому даже если оракл решится на такой шаг - мне кажется, это им только боком выйдет - все сразу же соскочат на форкиКак будто обилие проблем винды заставило всех соскочить на свободные системы? Платят (прямо или косвенно), мучаются, но продолжают пытаться испытать удовольствие.
Стереотип тем и силён, что не обязан быть правдой.
Но я не думаю, что реально это будет, потому что тогда придётся претензии реально к каждому сайту выдвигать, чтобы доказывал, что он не верблюд. Я только говорю, что это бы очень смешно выглядело со стороны. Хотя, постойте. Мне вспоминается что-то подобное: "Microsoft против андроидов", "Microsoft против linux-навигаторов", "Microsoft против linux-электроники". И как-то это выглядело совсем не смешно.
Кстати, oracle уже один раз изменила условия "заочно", в результате чего уже существующую java пришлось удалять из всех репозиториев. Там, глядишь, и в maria-системах обнаружатся какие-то "патенты", которые мы "не покажем", но которые непременно "нарушают".Это же капитализм, который защищает капиталы от человека. Человек человеку волк.
> Это же капитализм, который защищает капиталы от человека. Человек человеку волк.А опенсорс вот как-то работает, всем волкам назло. И как-то так более разумные существа начинают заруливать волчьи стаи, распихивая представителей по зоопаркам.
> Чу'дную ересь несёшь. Правда-правда.
> Даже если оракль переведет MySQL на AGPL3/GPL3 - всегда останется MariaDB или
> любой другой форк от того момента, когда оно было под GPL2.
> Это раз.а чем вам последователям столмана не нравится GPL v3 ? Вы же призываете сразу подписываться под всеми будущими лицензиями ставя GNU GPL vX or later...
> а чем вам последователям столмана не нравится GPL v3 ?Как раз наиболее радикальные последователи могут радоваться - такое воротило как оракл продавливает своей массой такую лицензию. Прямо странно даже.
> Как раз наиболее радикальные последователи могут радоваться - такое воротило как оракл
> продавливает своей массой такую лицензию. Прямо странно даже.И каноникал тоже свой убунтофон под GPLv3. Чудеса в решете!
А секрет просто - они всего лишь намекают вендорам, что неплохо было бы "договориться по-хорошему", с уплатой определенных сумм.
>> Как раз наиболее радикальные последователи могут радоваться - такое воротило как оракл
>> продавливает своей массой такую лицензию. Прямо странно даже.
> И каноникал тоже свой убунтофон под GPLv3. Чудеса в решете!
> А секрет просто - они всего лишь намекают вендорам, что неплохо было
> бы "договориться по-хорошему", с уплатой определенных сумм.О? Как мило! Вы ж бессеребренники, с бесплатным и безлимитным свободным временем! Какие еде суммы? Патчи от линя в уплату используйте, ёба!
> Какие еде суммы? Патчи от линя в уплату используйтеЛично меня вполне устраивают патчи которые чинят имеющиеся на моих конфигурациях проблемы :). Иногда это вполне себе кaтит за оплату.
А своими кoмплексами стyдня, вкaлывающего на проприетарей за дoширак можно и поменьше светить, вообще-то.
> Вряд ли они себе настолько враги.Cо здравым смыслом они не особо дружат, так что вполне ожидаемо.
Новые козни Оракли:) "компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии".
>Таким образом, введя требования по открытию кода web-сервисов, использующих Berkeley DB, компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии.Очень некрасиво получается. По сути весьма годная свободная лицензия используется Ораклом для вытрясания денег.
Та как раз наоборот, всё красиво.
Зарабатываете деньги - извольте поделиться, раз уж используете наш софт.
Не зарабатываете - используйте бесплатно.
Всё честно.
Только вот свободный софт, который, скажем, GPLv2 - уже несовместим получается... вот это плохо.
Лучше бы они v2 выбрали.
> Только вот свободный софт, который, скажем, GPLv2 - уже несовместим получается... вот
> это плохо.
> Лучше бы они v2 выбрали.несовместим получается мудофил, которого не устраивают условия AGPL
> несовместим получается мудофил, которого не устраивают условия AGPLАвторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы.
>> несовместим получается мудофил, которого не устраивают условия AGPL
> Авторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы.Ну так товарищь Столман сознательно их сделал не совместимыми.. Так в чем проблема ?:)
> Ну так товарищь Столман сознательно их сделал не совместимыми..Ага, а еще он ест детей.
> Ну так товарищь Столман сознательно их сделал не совместимыми.. Так в чем проблема ?:)Ну да, а ПДД сделали "несовместимым" с спортивными автомобилями, запретив гонять на 200 км/ч в городской черте. Вот ведь гады кто это ПДД придумал! Никакого покоя стритрэйсерам нет - постоянно копы мешают убиваться и других сшибать!
некоректное сравнение. Скорее уж так - вы едите едите на машине с круглыми колесами - и вдруг бац.. требование только на квадратных - и никакие аргументы что так не удобно - не влияют - подписался ехать по этой дороге - одевай квадратные или вали с нашей дороги.
Требование открытости кода, который ты _распространяешь_ (а не используешь для нужд своей фирмы) == квадратные колеса?Походу, у тебя в голове баг. И, возможно, даже не один.
Но уж никак не требование ПДД не гонять :-) Ближе к квадратным колесам..Хотя может ближе к тому что - ты взял прокатиться велосипед - а у тебя начали выворачивать карманы под предлогом что ты съездил в банкомат и снял деньги, а значит попользовался велосипедом и получил прибыль?
> подписался ехать по этой дороге - одевай квадратные или вали с нашей дороги.Не, не так. Если тебе не нравится ПДД - вали, создавай другое государство, становись президентом и принимай там другое ПДД. Если принималка не сломается.
>> несовместим получается мудофил, которого не устраивают условия AGPL
> Авторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы.взяли — и заменили v2 на v3. что? в проекте написано v2 only? идиоты должны страдать.
> Та как раз наоборот, всё красиво.
> Зарабатываете деньги - извольте поделиться, раз уж используете наш софт.
> Не зарабатываете - используйте бесплатно.
> Всё честно.Всё бы правильно, да ведь и на свободном движке можно зарабатывать деньги, совершенно спокойно. В тех же web-сервисах, зачастую, решает контент и раскрученность, а также пользовательская база, чему открытый исходный код не только не мешает, но может и помочь.
> Всё бы правильно, да ведь и на свободном движке можно зарабатывать деньги,
> совершенно спокойно. В тех же web-сервисах, зачастую, решает контент и раскрученность,
> а также пользовательская база, чему открытый исходный код не только не
> мешает, но может и помочь.Один момент - безопасность.
Воспользоваться уязвимостью веб-движка гораздо проще, чем уязвимостью в прикладной программе. Поэтому в ход должны пускаться все возможные методы защиты, вплоть до security by obscurity.
> security by obscurity.Т.е. впаривания лоху г@вна завернутого в красивый фантик. Называя вещи своими именами.
> Т.е. впаривания лоху г@вна завернутого в красивый фантик. Называя вещи своими именами.Опенсорсность никак не мешает этому процессу, как показал нам коcмонавт.
> Опенсорсность никак не мешает этому процессу, как показал нам кocмoнавт.А у кoсмoнавта, btw, вполне нормальная система. Не хуже остальных. С точки зрения пользователя - там симпатичные темы, шрифты и прочая из коробки, более-менее нормальная подборка софта для повседневных задач и прочая. А в остальном - тот же дeбиан, вид в профиль. Ну, цикл релизов еще повмeняемее для десктопа чем у оригинала. В остальном - попробуйте найти 10 различий.
ИМХО как раз удачно вышло: дебиан хорош как база, а каноникал хороши как те кто отпoлировал видимые юзерям шерoховатости в этой базе.
Что и требовалось доказать.
> Что и требовалось доказать.От дополнительной полировки дебиан в г@вно отнюдь не превратился. Как ни странно, в красивую обертку можно еще и конфеты класть. Вот Дебиан - конфеты в развес, без фантиков вообще. А убунта - "retail" версия, уже с фантиками и подороже.
Был довольно пaршивый дистр (кстати из недавнего: замечательная идея - при минорном обновлении софтины грохать базу, которую эта софтина использует), который при помощи арч-стайл пиoнерии был превращен в тормозное и глюкaвое минное поле, которое дохнет от малейшего обновления.
Но технический аспект, как известно, ничто, а рулить только пиар. И хомячки бодро ринулись на мины. ИЧСХ, даже ежедневно подрываясь на них, продолжают их нахваливать.
> Был довольно пaршивый дистрДебиан вполне обычен и даже зауряден как дистр, но есть и несколько козырей.
1) У них хороший пакетный менеджер. Лучше чем у многих других.
2) У них куча пакетов в репозиториях на все вкусы.
3) Это замечательная "база" для построения на его основе деривативов. Потому как щепетильны к лицензиям, патентам и прочему.> (кстати из недавнего: замечательная идея - при минорном
> обновлении софтины грохать базу, которую эта софтина использует),Кстати, идеального софта в этом мире не бывает - можно до...ться к любой программе сложнее hello world. А к дистру с 20 000+ пакетов можно априори до...ться по туевой хуче предъяв.
Кстати, а это в stable было? Если нет - ну вы сами себе злобный баклан, потому что названия "testing" и "unstable" прозрачно намекают, если что. В stable подобные приколы обычно себе никто не позволяет. В более камикадзевых ветках - зависит от.
> который при помощи арч-стайл пиoнерии был превращен в тормозное и глюкaвое минное поле,
Не вижу ничкакой арч-стайл пиoнерии. А глючит там только питонятина от каноникала. Которую можно просто выпилить за 5 минут манагером пакетов, т.к. нафиг все эти ubuntu one и софтвар центры, скажем честно :)
> которое дохнет от малейшего обновления.
И, конечно же, нас завалит пруфами? :)
> Но технический аспект, как известно, ничто, а рулить только пиар.
Технический аспект у граждан вполне нормальный. Не хуже чем у остальных. А вы свой любимый дистр назовите - мы ему тоже по техническим моментам косточки пересчитаем.
> Поэтому в ход должны пускаться все возможные методы защиты, вплоть до
> security by obscurity.«security by obscurity» — это метод не защиты от уязвимостей, а защиты уязвимостей от клиентов.
> «security by obscurity» — это метод не защиты от уязвимостей, а защиты
> уязвимостей от клиентов.Не только от клиентов.
Хотя от того же тупого пентестинга сканером, конечно, не защитит никак.
в основном — от клиентов и security reviewers. о чём клиент не знает — того нет. и заказать аудит сторонним экспертам сильно сложнее, потому что надо или реверсера дополнительно брать, или за код бодаться.
> Очень некрасиво получается. По сути весьма годная свободная лицензия используется Ораклом для вытрясания денег.Свободные лицензии - это MIT, BSD, Apache, Boost. *GPL же изначально вводились в оборот сугубо для отжатия бабла. И, надо признаться, весьма успешно действуют на этом поприще.
А ваши "свободные" - для отжатия халявной рабсилы. С чем тоже успешно справляются.
> А ваши "свободные" - для отжатия халявной рабсилы. С чем тоже успешно
> справляются.Чума на оба ваших дома.
>> По сути весьма годная свободная лицензия используется Ораклом
> Свободные лицензии - это MIT, BSD, Apache, Boost. *GPL же изначально вводились
> в оборот сугубо для отжатия бабла. И, надо признаться, весьма успешно
> действуют на этом поприще.То ли дело NVidia, VIA, ARM, Juniper, ...Apple! "Great Artists Steal." *Такие* мо-лод-цы!! </opa izenмэн style>
Такие мо-лод-цы ещё и деньги _раздают в отличие от суппостата Столмана!
Да! И работают на Благо _за_еду_, гусары с дамм денег не берут.
> </opa izenмэн style>Открывающий тег потерял. Валидатор не одобряет.
> Открывающий тег потерял. Валидатор не одобряет.Настоящий парсер ставит нужные теги по контексту сам. А вот тyпоботы - палятся, их валидатор не может отслеживать контекст :)
>А вот тyпоботы -
> палятся, их валидатор не может отслеживать контекст :):)
Тест Тьюринга: NO CARRIERНеожиданно положительный результат.
>> Очень некрасиво получается. По сути весьма годная свободная лицензия используется Ораклом для вытрясания денег.
> Свободные лицензии - это MIT, BSD, Apache, Boost. *GPL же изначально вводились
> в оборот сугубо для отжатия бабла. И, надо признаться, весьма успешно
> действуют на этом поприще.Оть иманна.
GPL как раз вводилась в оборот, чтобы всякие умники-коммерсанты не могли отжимать бабло с нормальных людей. И чтобы софт был действительно свободным. А не как в BSD-лицензиях, когда хромиум свободный, а хром всё равно закрытый и с гуглозондами.
С хромом плохой пример, например mysql прекрасно бывают и свободная и коммерческая.
Ну дык правообладатель может выдавать кому угодно какие угодно лицензии.
Хм... Ну да. Но не факт, что гугл бы был эксклюзивным правообладателем вебкита...
> Свободные лицензии - это MIT, BSD, Apache, Boost.Список проприетарных подстилок не полный. MS PL где? Как посмотришь на продукцию эпплов и жуниперов - оттуда свобода так и прет во все щели :)
ты перепутал - эти лицензии признаны свободными и открытыми.
> ты перепутал - эти лицензии признаны свободными и открытыми.Открыты они прежде всего для проприетарщиков.
> ты перепутал - эти лицензии признаны свободными и открытыми.Я не знаю для кого оно там свбодное и открытое, но если я куплю железку от жунипера, эппла или сони - я что-то совсем не наблюдаю там обещанных свобод. Походу свобода есть только у этой троицы, а у остальных - только дырка от этого бублика.
Да, эти лицензии свободные. Но не для тебя.
>> ты перепутал - эти лицензии признаны свободными и открытыми.
> Я не знаю для кого оно там свбодное и открытое, но если
> я куплю железку от жунипера, эппла или сони - я что-то
> совсем не наблюдаю там обещанных свобод.Обещаных кем? цитату плиз?
Я вот вижу как RedHat обещавший всего и много - потихоньку закрывает бизнес.. Вот уже и FAQ закрытым стал.. только по подписке..
> Я вот вижу как RedHat обещавший всего и много - потихоньку закрывает
> бизнес.. Вот уже и FAQ закрытым стал.. только по подписке..Да и в LKML уже патчи не присылают...
> Да и в LKML уже патчи не присылают...Ну да, а какой-нибудь Дэйв Эйрли из редхата в курсах о том какой он там жадный жлоб? А в графической подсистеме его копирайтов - хоть отбавляй. Да, в исходниках ядра. На моем диске. Это редхат, значит, такой жадный и ничего не присылает? :)
> Ну да, а какой-нибудь Дэйв Эйрли из редхата в курсах о
> том какой он там жадный жлоб? А в графической подсистеме его
> копирайтов - хоть отбавляй. Да, в исходниках ядра. На моем диске.
> Это редхат, значит, такой жадный и ничего не присылает? :)Ну так Linux - проприетарное пoделие, это тебе любой линуксмастрип расскажет.
> Обещаных кем? цитату плиз?Да вон вы утверждаете же "ты перепутал - эти лицензии признаны свободными и открытыми". Кем-то может и признаны, а если я куплю что-то от сони, жунипера и эппла - мне с этого только дырка от бублика достанется а не "свобода". Нафига бы мне такой расклад?
> Я вот вижу как RedHat обещавший всего и много - потихоньку закрывает
> бизнес.. Вот уже и FAQ закрытым стал.. только по подписке..Тем не менее, у меня в ядре довольно много кода от этого самого редхата вкалывает на мое благо. А все остальное меня честно говоря интересует довольно слабо.
Хм.. код который взял кто-то и под себя додел что куда-то пропал? вы его взять не можете?
Или вы хотите на халявую чужую работу взять?
> Хм.. код который взял кто-то и под себя додел что куда-то пропал?
> вы его взять не можете?Внезапно, да. У сони на PS4 есть игры. А на фрибсдах - дырка от бублика. И уж конечно никаких патчей от сони. И вообще конкретная з@дница с драйверами GPU.
> Или вы хотите на халявую чужую работу взять?
Ну если мою работу можно брать нахаляву, тогда и я хочу так же мочь. А что, я самая главная дойная корова вам тут чтоли? Пусть корпорасы бесплатно катаются на вашей хребтине, если вам это по кайфу. А как по мне - или уж "равный-равный", или уж "GTFO". Участвовать в процессе на условиях второго сорта и бесплатной рабсилы мне нет никакого резона.
> ты перепутал - эти лицензии признаны свободными и открытыми.Они также являются свободными для _закрытия_. В отличие от. Это коренно-и-отлично, да.
> для вытрясания денег.Или отдачи в проект. Второй вариант не так уж и плох.
> Или отдачи в проект. Второй вариант не так уж и плох.Вы таки действительно верите в то, что Оракел спит и мечтает, чтобы ему кто-то что-то куда-то отдавал?!
> Вы таки действительно верите в то, что Оракел спит и мечтает, чтобы
> ему кто-то что-то куда-то отдавал?!Гм, вообще, ситуация когда корпорас отпинывается ногами от желающих поработать на них совершенно бесплатно - видится мне довольно странной и дикой. Это как-то совсем не по капиталистически прямо.
> Гм, вообще, ситуация когда корпорас отпинывается ногами от желающих поработать на них совершенно бесплатно - видится мне довольно странной и дикой. Это как-то совсем не по капиталистически прямо.Народное правило "Скупой платит дважды" ещё никто не отменял.
Оракл - это корпоратив. Со своим workflow разработки, требованиями к коду и тд и тп. Попытки встроить в эту структуру механизм принятия патчей от сторонних разработчиков с большей вероятностью приведут к фейлу. Геморрою вагон с тележкой а сухого остатка - пшик. При таком раскладе естественное решение вопроса приема сторонних патчей - тупо посылать их лесом и не заморачиваться. Благо, в случае необходимости своих кодеров у Оракла в достатке.
GPL в обсуждаемом случае - это отнюдь не инструмент привлечения сторонних разработчиков в проект ибо они там нахрен никому даром не сдались. Это shareware чистой воды. Хотите попробовать? Берите, пробуйте как вам угодно - не вопрос. Хотите реально использовать? Платите и используйте. Решили остаться на GPL версии? Бога ради. Вы не наш клиент. Следующий.
> Народное правило "Скупой платит дважды" ещё никто не отменял.Вот проприетарщики и ощущают это на своей попе во весь рост, все сильнее и сильнее :)
> Оракл - это корпоратив. Со своим workflow разработки, требованиями к коду и тд и тп.
> Попытки встроить в эту структуру механизм принятия патчей от сторонних разработчиков с
> большей вероятностью приведут к фейлуУ бездарей - приведут. А вон в линевом кернеле например прокатило. Выбрали некие условия которые более-менее всех устроили, ну и работают по ним. Достаточно предсказуемо, кстати. Кровавым ынтырпрайзам и то понравилось даже. Хотя некоторые предпочли вратаря на воротах содержать, типа редхата или кого там еще.
Вообще, это ужасно, что BERKELEY DB не под родной лицензией BSD (BERKELEY Software Distribution)... Они теряют корни.
Вступят в евросоюз
> Berkeley DB входит в числе базовых библиотек, от которых зависят многие пакеты.несмотря на это, bdb мало где используется по факту и мало где является ключевым незаменимым компонентом. Нефиг собирать пакеты со всеми ненужными зависимостями и тем самым делать их базовыми.
Эээ "редко, но метко". rpm использует bdb, а это ключевой компонент многих дистрибутивов.Также Berkeley DB нужен для pam (не уверен, может ли pam использовать что-то еще, но в разных дистрибутивах, где сейчас проверил, везде использует bdb). Без pam нынче нормально можно жить разве что в ембеддовке.
Ну и до кучи, iproute2 требует bdb. Тут вообще без комментариев.
>нужен для pam
>iproute2 требует bdb. Тут вообще без комментариев.
15.02.2006 12:42 Компания Oracle купила Sleepycat SoftwareАй-яй-яй, за ними пришёл пушистый маленький оракел!??
> Эээ "редко, но метко". rpm использует bdb, а это ключевой компонент многих дистрибутивов.с rpm'ом это проблема, но тем не менее не сложно переписать на других аналогах. Да и не дебиановская пичаль.
> Также Berkeley DB нужен для pam (не уверен, может ли pam использовать что-то еще, но в разных дистрибутивах, где сейчас проверил, везде использует bdb)
в PAM bdb используется для эзотерических фич и в большинстве практических кейсах никогда не юзается. Собирается оно опционально и есть в разных дистрибутивах только потому, что какой-то удак решил собирать PAM с данной опцией.
> Ну и до кучи, iproute2 требует bdb.
аналогично, нафиг не нужен и прекрасно в % 99.9 кейсах работает без него. Собрали с ним ~ 'шоб было'
я же об этом именно и пишу выше, что почти везде в бинарных дистрибутивах приклеили bdb от нефиг делать. И само использование bdb является оверкилом в 9 из 10 пакетах, какого-нибудь gdbm вполне хватает для требуемой функциональности.
> Также Berkeley DB нужен для pam (не уверен, может ли pam использовать
> что-то еще, но в разных дистрибутивах, где сейчас проверил, везде использует
> bdb). Без pam нынче нормально можно жить разве что в ембеддовке.Хм. Слаководы вполне себе живут без PAMа, потому что им гуру запретил.
> Хм. Слаководы вполне себе живут без PAMа, потому что им гуру запретил.Да им не привыкать, там вся система - "...и удобства во дворе".
> "...и удобства во дворе"Удобства не нужны же.
> Удобства не нужны же.Только зимой ж@па мерзнет, а так ничего.
> Только зимой ж@па мерзнет, а так ничего.Потому что ты идиoт. А я умный, у меня ничего не мерзнет. © arisu
> Потому что ты идиoт. А я умный, у меня ничего не мерзнет. © arisuАга, можно конечно ставить костыли своему "скворечнику" и даже буржуйку для отопления поставить. Но нормальные люди ставят в доме унитаз а не занимаются извращениями с окультуриванием "скворечника" и воркэраундом проблем.
угу. вот я и не занимаюсь борьбой с системой вместо нормального её использования.
> угу. вот я и не занимаюсь борьбой с системой вместо нормального её использования.Вполне имеющий право на жизнь подход. Тебе так удобно - ну и ладушки. А мне ваш деревянный меч который "типа, пакетный менеджер" кажется забавным.
> А мне ваш деревянный меч который «типа, пакетный менеджер» кажется забавным.да на здоровье. вообще, в слаке штатно есть post-install скрипты, а зависимости опциональны, и для них написан slapt-get — как надстройка над стандартными пакетными утилитами. другое дело, что если человек выбрал слаку — то он, скорее всего, этим пользоваться всё равно не станет.
основной же посыл был в том, что «я сам не работал, но мне сосед рассказал, и я осуждаю» — не очень умная позиция. особенно в спорах с тем, кто использует слаку больше десяти лет, и явно знает систему сильно лучше.
> да на здоровье. вообще, в слаке штатно есть post-install скрипты, а зависимости
> опциональны, и для них написан slapt-get — как надстройка над стандартными
> пакетными утилитами. другое дело, что если человек выбрал слаку — то
> он, скорее всего, этим пользоваться всё равно не станет.Ну дык слаку пользуют обычно олдскульщики, которые удобствами не избалованы. Так, по наблюдениям. Осталось еще пробубнить что-то типа "да нафиг надо этот ваш JTAG, вот тумблеры на шине с кнопкой пошаговой отладки - это труЪ" :).
> основной же посыл был в том, что «я сам не работал, но
> мне сосед рассказал, и я осуждаю» — не очень умная позиция.Оценить то или иное решение и его (не)соответствие пожеланиям к решениям такого класса можно и не становясь супер-гуру в конкретном решении которое все-равно будет отсеяно как неподходящее на самой ранней стадии.
> особенно в спорах с тем, кто использует слаку больше десяти лет,
> и явно знает систему сильно лучше.Так я вроде и не пытаюсь тебя твоей слаке обучать :). Просто попытки бряцания тем что гольный тарбол без нишиша это лучший формат для пакетов вызывает у меня некоторое недоумение: технических аргументов "за" не приведено, а некоторые очевидные "против" я могу и сам придумать на лету, чисто на основании моих знаний форматов файлов и их сильных и слабых мест.
> Ну дык слаку пользуют обычно олдскульщики, которые удобствами не избалованы.наоборот. как раз удобствами мы очень избалованы. а вот от свистелок и перделок нас тошнит.
> наблюдениям. Осталось еще пробубнить что-то типа «да нафиг надо этот ваш
> JTAG, вот тумблеры на шине с кнопкой пошаговой отладки — это
> труЪ» :).ну, про jtag я промолчу, а вот у gdb, например, полезность с моей точки зрения очень небольшая. в том плане, что он хорошо подходит для ковыряния кородампов.
> Оценить то или иное решение и его (не)соответствие пожеланиям к решениям такого
> класса можно и не становясь супер-гуру в конкретном решении которое все-равно
> будет отсеяно как неподходящее на самой ранней стадии.особенно если думаешь, что оно только вот такое, и никаких дополнительных фич нет вообще (и что их надо руками корячить с нуля).
> Так я вроде и не пытаюсь тебя твоей слаке обучать :)
тем не менее о слаковых пакетных менеджерах зачем-то высказываешься.
> попытки бряцания тем что гольный тарбол без нишиша это лучший формат
> для пакетов вызывает у меня некоторое недоумениеон *достаточный* в большинстве случаев. особенно если учесть, что техника сейчас весьма шустрая, и добыть метаданные из тарбола не особая проблема. впрочем, стандартные слакотулзы отлично понимают и случай, когда метаданные лежат рядом с пакетом в обычном текстовике: это для тех, кого не устраивает скорость «добычи».
> технических аргументов «за» не приведено
kiss. я, опять же, нигде не говорил, что тарбол — лучший формат. но, как уже сказал выше, он достаточен для большинства случаев.
> наоборот. как раз удобствами мы очень избалованы.У вас там довольно специфичное понимание удобств :). "Зато я могу сходить в мой сортир независимо от выходок коммунальщиков!". Ну да, фиг оспоришь.
> а вот от свистелок и перделок нас тошнит.
Просто особо упертые олдскульщики считают свистелками и перделками почти все что выходит за пределы черно-зеленого терминала на RS232. Ну так, если утрировать немного :).
> ну, про jtag я промолчу,
Кстати раз уж ты про GDB - он умеет с ним работать, ага. Вот такие вот навороты - можно трэйсить состояние софта в некоем чипе по out of band интерфейсу :). Иногда может быть полезно.
> а вот у gdb, например, полезность с моей точки зрения очень небольшая.
> в том плане, что он хорошо подходит для ковыряния кородампов.Не совсем понимаю как без дебагера понять где сложная программа факапнулась. Ну да, устранение багов класса "крах" и прочего веселья - совсем такая небольшая польза, чо :)
> особенно если думаешь, что оно только вот такое, и никаких дополнительных фич
> нет вообще (и что их надо руками корячить с нуля).И что характерно, чаще всего как-то так и оказывается. Ну и кроме
>> Так я вроде и не пытаюсь тебя твоей слаке обучать :)
> тем не менее о слаковых пакетных менеджерах зачем-то высказываешься.Затем что если некто полагает что трекинг зависимостей это опционально и чисто для галочки - мне с ними все понятно. Для меня это не просто mandatroy, для меня это ключевой момент в пакетном менеджере, очень сильно разгружающий меня от системной рутины. А у слакваристов как ты сам сказал - это побочный сценарий, до кучи. Ну а как работают побочные сценарии в софте - я в курсе: не первый год в индустрии разработки ПО :).
В таких случаях обычно обнаруживается что культурная комнатка с унитазом как бы есть, но питальник к насосу для откачки результатов - не подсоединен. Потому что все уже привыкли пользоваться милым сердцу скворечником во дворе :)
>> попытки бряцания тем что гольный тарбол без нишиша это лучший формат
>> для пакетов вызывает у меня некоторое недоумение
> он *достаточный* в большинстве случаев.Весьма спорный тезис, имхо. Просто потому что формат тарбола не подразумевает быстрого извлечения из него частичных данных. Значит метаданные по быстрому вынуть будет не судьба. А это уже означает очень характерный набор проблем и соответствующую коррекцию сценариев использования.
> особенно если учесть, что техника сейчас весьма шустрая,
Это не повод делать себе крупную гадость на уровне базовой алгоритмики.
> и добыть метаданные из тарбола не особая проблема.
Угу, так и представляю себе парсинг 20К пакетов с чуть ли не полной распаковкой вообще всей этой кипы. Оптимальность такого подхода поражает воображение. Как раз в этом плане те же deb-пакеты смотрятся очень здраво: мелкий файлик с метаданными отдельно лежит и его адресно и быстро выцепить без распковки основного тарбола на 100500 Мб очень даже можно.
> впрочем, стандартные слакотулзы отлично понимают и случай, когда метаданные
> лежат рядом с пакетом в обычном текстовике: это для тех, кого не устраивает скорость «добычи».Меня также совершенно не устраивает гадеж в файловую систему какими-то лишними файлами которые мне самому в 99.9% - нафиг не упали. Я нахожу чертовски логичным что все что надо - лежит в пакете, но при необходимости достается оттуда по быстрому. А для полной красоты - еще и индексится в базе чтобы ускорить некоторые операции.
>> технических аргументов «за» не приведено
> kiss.Это уже звучит разумнее, однако почему-то почти никто не ходит пешком из питера в москву. Хотя идти пешком как бы вроде проще чем содержать целую железную дорогу с поездами и большой инфраструктурой. Наверное, кроме простоты есть еще параметры того что в результате получилось.
> я, опять же, нигде не говорил, что тарбол — лучший формат.
Ну вот на мое мнение, тарбол как формат пакетов - примерно как деревянный "костотряс" в роли велосипеда. Т.е. как-то и это поедет, конечно. Вопрос только в удобстве ездока.
> но, как уже сказал выше, он достаточен для большинства случаев.
Ну как бы у всех свои понятия о достаточности и большинстве. Мне вот например удобен трекинг зависимостей в 99.9% случаев и тулса с мощными средствами для всего этого. А в оставшихся 0.1% случаев - окей, 2 пакета из 2000 я так и быть вручную заоверрайдить могу. Если это реально потребуется.
> Хм. Слаководы вполне себе живут без PAMа, потому что им гуру запретил.потому что оно нам нафиг не надо. но ты, конечно, продолжай рассказывать чушь про слаку: чем больше про слаку чуши расскажут, тем меньше дебилов к нам придёт. вот маркова бы ещё кто забрал…
>вот маркова бы ещё кто забрал…Покайсо, и избавит тебя Господь от наказания за грехи твоя... Либо терпи, ибо сказано в ман^W Писании - Господь не дает вам испытаний, кои не силам вашим.
> потому что оно нам нафиг не надо.Что вам надо, а что нет - решать не вам, а Патрику. Ибо воистину.
> Что вам надо, а что нет - решать не вам, а Патрику.
> Ибо воистину.За кого-то решает Патрик, за кого-то Леннарт, за кого-то Марк.
Но все, сцуко, как один, кричат "Мы не хомячки, мы умеем думать своей головой, а ты просто идиoт!!111".
> Но все, сцуко, как один, кричат "Мы не хомячки, мы умеем думать
> своей головой, а ты просто идиoт!!111".Ну так все правильно. Линух же не винда или макось где все гвоздями приколочено. Можно и дистр наиболее похожий на желаемое выбрать, и быстренько его довести до желаемого вида потом. И никакой Патрик, Леннарт или Марк не сможет оспорить например вынос некоего пакета пакетным менеджером. У них чисто технически такой возможности нет :)
Удобство оверрайда может варьироваться. Но право на оверрайд и рукоятки для оного есть. Кто ими сможет пользоваться и насколько это будет удобно - второй вопрос. Но - можно, если хочется. Да, придется поработать. Но это по любому придется - никто не знает что нужно вам и вероятность что лично под вас сделают софт устраивающий в 100% случаев - крайне низкая.
>> потому что оно нам нафиг не надо.
> Что вам надо, а что нет — решать не вам, а Патрику.меня не обещали зверски убить, если я сменю дистрибутив или пересоберу пакеты так, как мне понадобится. так что решать мне, просто мои предпочтения в основном совпадают с предпочтениями маинтайнеров слаки.
У тебя в основном нет предпочтений. За тебя предпочитают мейнтейнеры слаки :)
как у тебя пердак-то жжот.
> как у тебя пердак-то жжот.У меня? С чего бы? Мои религиозные чувства не были оскорблены (да и нельзя их оскорбить, ввиду их отсутствия).
А вот с твоими чувствами обошлись весьма гадко, это да. И ты тут же с дымящимся хвостом побежал доказывать, что жжет вовсе не у тебя :)
>> как у тебя пердак-то жжот.
> У меня? С чего бы?а я откуда знаю? пердак-то у тебя дымится.
> а я откуда знаю? пеpдак-то у тебя дымится.Фу, как неуклюже. Напоминаешь упоpотого бздишника в соседнем треде - над ним уже в открытую стeбутся, а он все тыкает пальцем и визжит "у тебя батxерт! у тебя батxерт!!1". Походу, все остальные слова просто из головы вылетели. Под воздействием подогрева снизу :)
>> а я откуда знаю? пеpдак-то у тебя дымится.
> Фу, как неуклюже.я же не виноват, что ты дурак.
> я же не виноват, что ты дурак.То, что мне, дураку, удалось заставить тебя, такого умного, добровольно прыгнуть в помойку и покувыркаться там - уже неплохо. Смех действительно продлевает жизнь. А у тебя, к тому же, и так природная склонность, поэтому не такой уж я и злодей :)
где я сказал «злодей»? я сказал «дурак». ты читать, что ли, не умеешь?
Вопрос о моем злодействе тебя не касается. Это так было, замечание на полях.
Успокойся уже, валокординчику попей. А то бессонница замучает, завтра будешь вялый и несмешной :)
больше заискивающих смайлов давай.
> где я сказал «злодей»? я сказал «дурак». ты читать, что ли, не
> умеешь?Арису, ты знаешь, а дураком-то ты выглядишь.
> Арису, ты знаешь, а дураком-то ты выглядишь.А вы еще тупее выглядите. У arisu хотя-бы аргументы просматриваются. А у вас только шакалье тявканье.
аргументы у меня есть всегда, просто большинство «оппонентов» показывают свой уровень буквально парой комментариев. после чего вести какую-то аргументированую дискуссию я смысла уже не вижу.
> Арису, ты знаешь, а дураком-то ты выглядишь.мне можно, я и вправду дурак. хоть и гений.
LMDB: http://symas.com/mdb/в частности: "Since the LMDB API is similar to BerkeleyDB, porting existing BDB-based code to LMDB is usually quite simple and fast."
ребята, собственно, и написали его как замену bdb для OpenLDAP.
Вангую взлёт SQLite.
> Вангую взлёт SQLite.Так оно уже давно взлетело. В браузерах, например.
> Так оно уже давно взлетело. В браузерах, например.Только слопупочит немилосердно на некоторых операциях без костылей. Хотя слоупочить - это в целом умение скулей вообще :)
Да там не из-за SQL слоупочность. Там во время записи блокируется весь файл целиком, параллельная запись невозможна (мб что и изменилось, мог отстать от жизни).
> Да там не из-за SQL слоупочность. Там во время записи блокируется весь
> файл целиком, параллельная запись невозможна (мб что и изменилось, мог отстать
> от жизни).Сами по себе множественные writer'ы - это уже заявка на большой и крутой двигун БД, к тому же на мощной дисковой подсистеме (обычному единичному механическому диску удобнее как раз 1-поточная работа в общем случае).
Собственно BDB обычно юзают как глупую но быструю базу ключ-значение, которая может быстро выколупывать нужные записи. Намного быстрее чем это светит скулю.
Другое дело что я не понял чем этот BDB так всем понравился. Ну вон токийский кабинет есть, под LGPL. Тоже ключ-значение, тоже быстрый. Даже быстрее BDB вроде.
Ну хотя у BDB апи достаточно логичное + в свое время их разработчики были достаточно контактабельны, как сейчас - не знаю, а в свое время они мне помогли с рядом багов справиться. В целом sleepycat были достаточно прикольной такой конторкой, потом их оракл скушал. И вроде даже ничего особо не испортил как ни странно. Видимо столь мелкая база им не особо интересна и давиться жабой там негде особо было.
> Ну вон токийский кабинет есть, под LGPL.это же плюсовое дерьмо на шаблонах, +1МБ к бинарю и прочие плюсовые пакости. Нахер его. bdb однозначно лучше.
>> Ну вон токийский кабинет есть, под LGPL.
> это же плюсовое дерьмо на шаблонахты попутал tokyo cabinet и kyoto cabinet. а ещё qdbm есть.
> это же плюсовое дерьмо на шаблонах,Вас жестоко глючит, токийский кабинет на голом си написан :)
> +1МБ к бинарю и прочие плюсовые пакости.
Это наверное было про kyoto cabinet. Ну да, tokyo, kyoto, какая папуасу разница? :)
> bdb однозначно лучше.
У bdb кода больше чем в токийском кабинете, пожалуй. И он быстрее. И апи у него попроще, пожалуй. Хотя в целом bdb довольно приятная штука, imho.
> Вангую взлёт SQLite.Сравнил попу с пальцем. А ничего что скулайт не умеет kev-value, в отличие от? А скуль - тормозной и опасность иньекций к тому же есть. BDB в режиме SQL практически никто не юзает - их как базу key-value обычно пользуют, каковой они всегда и были. Скуль они потом до кучи немного прикрутили и большинству пользователей BDB он нафиг не упал.
Я в курсе. Но из embedded движков логичнее выбрать SQLite, если конечно параллелизм на записи не требуется. И - да - любой реляционный движок легко позволяет сэмулировать key-value storage :)
> Berkeley DB входит в числе базовых библиотек, от которых зависят многие пакеты. В связи с этим поставлен вопрос, допустима ли поставка базовых библиотек под AGPLv3, так как связывание с AGPLv3-библиотекой приведёт к распространению лицензии AGPLv3 на все использующие данную библиотеку пакеты.Не ужели? да как они могли.. А вот когда gcc такую шутку провернул с libgcc - все дружно набрали воды в рот.. И ставили столмана..
> Не ужели? да как они могли.. А вот когда gcc такую шутку провернул с libgcc - все дружно набрали воды в рот.. И ставили столмана..RTFM однако: http://www.gnu.org/licenses/gcc-exception-faq.html
Что впрочем не удивительно - быстрой смерти GCC после полного перевода рантайма на честный *GPL никому не нужно.
что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него..
Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.
> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.Я не в курсе деталей этой истории, но лично мне ничего удивительного в ней не видится. Полагаю, что сперва Столман & K решили как водится 'до основания а затем'. Но чуть позже трезвые товарищи по партии доходчиво объяснили им, что столь радикально делать не стоит. Иначе они останутся со своим полностью свободным GCC в гордом одиночестве в том числе без толстых спонсоров. Благо, конкурентов GCC хватает.
Вот вот.. Пусть делают свой самый свободный компилятор..
А то "ложечки нашлись - но ведь осадочек остался" ?Что еще эта компания сделает?
Хотя вот разработчики Debian оказались не рады AGPL v3.. почему - не подскажете ?
> Хотя вот разработчики Debian оказались не рады AGPL v3.. почему - не подскажете ?удаки и идоры потому что. Сегодня лишний раз в этом убедился (да, и это никак не относилось к лицензионным вопросам).
> Благо, конкурентов GCC хватает.Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать. Но именно эта история спровоцировала бурное развитие Clang/LLVM.
Видать Oracle патологически не способен учиться на чужих ошибках...
>> Благо, конкурентов GCC хватает.
> Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать.
> Но именно эта история спровоцировала бурное развитие Clang/LLVM.наверно вы помните - что ядро Clang собирал уже давно. Но слишком много "программистов" не знаю слово "стандарт на язык", а пишут как привыкли/научили - с кучей компиляторо-зависимого кода.
Могу больше сказать - попытка собрать ядро при помощи gcc с флагами -pedantic обречена на неудачу - в основном из-за такой вот кривизны кода.
> наверно вы помните - что ядро Clang собирал уже давно.Давно это 2-3 года? Сравните например с возрастом проекта GNU GCC (1987 год) или Linux-ядра (1991 год). Это то, что я называю словом давно. А Clang еще младенец, хоть и невероятно продвинутый...
> Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать. Но именно эта история спровоцировала бурное развитие Clang/LLVM.Как раз сборка ядра - это совсем не показатель. Его можно собирать всем, чем угодно. По всей очевидности все той же GCCой под какой бы лицензией оно не шло. Это никак не повлияет на проекты в userland. А вот выпуск рантайма GCC под AGPL - это уже, простите, совсем другой коленкор. Это напрямую затрагивает закрытые проекты. У них не останется никакого выбора, кроме как смотреть на альтернативы. И если Clang сможет предоставить вменяемую реализацию компилятора C++, то это будет более чем реальная альтернатива GCC и переход коммерческих проектов с GCC на тот же Clang будет лишь вопросом времени причем весьма скорого. С учетом того, что GCC - это пожалуй основной реально востребованный проект GNU, подобный переход очень и очень больно ударит по FSF. В том числе и финансово. У многих крупных коммерческих вендоров отпадет сам смысл с ними особо возиться. Оно FSF такое надо?
> Как раз сборка ядра - это совсем не показатель. Его можно собирать
> всем, чем угодно.Я молча развожу руками... Может продемонстрируете?
tcc когда-то собирал ядро прямо при загрузке. было забавно.интересно, способен ли он до сих пор на такой фокус?
> tcc когда-то собирал ядро прямо при загрузке. было забавно.
> интересно, способен ли он до сих пор на такой фокус?ТССBOOT собирал адаптированные исходники собранные в ISO-образ. ТСС ничего не знает про расширения системы команд x86 типа SSE/SSE2. Я уже не говорю про код KVM в ядре...
вообще-то с тех пор tcc значительно подрос. и да: ядро таки может работать и без sse, и даже без kvm.
> работать и без sse, и даже без kvm.Ну да, а еще можно руку ампутировать. Печатать на клавиатуре и одной рукой можно. Зачем тебе лишние запчасти?!
> Ну да, а еще можно руку ампутировать. Печатать на клавиатуре и одной
> рукой можно. Зачем тебе лишние запчасти?!а зачем мне в ядре sse и kvm? не «зачем оно вообще надо?», а «зачем оно лично мне?»
> а зачем мне в ядре sse и kvm? не «зачем оно вообще
> надо?», а «зачем оно лично мне?»Зачем лично тебе - не знаю, за отсутствием телепатического устройства.
Лично мне оно например затем что
1) Я запускаю KVMные виртуальные машины. Очень удобно для системокрушильных экспериментов. Убабахать в процессе виртуалку - одно, ее к снапшоту откатил и порядок. А раздестроить нето в основной системе - да ну нафигЪ :)
2) С SSE намного быстрее работает код для RAID5/6 и шифрование, например. Буквально кипа модулей ядра при возможности юзает самые современные наборы инструкций.И да, знаешь, там кроме всего прочего в dmesg пишется результат бенчмарков. И я имею отметить что от новых инструкций есть толк: самые забористые реализации алгоритмов на новейших командах могут делать старые SSE в несколько раз. А без SSE - вообще сталинград.
А просадить половину криптографии и кода рэйдов в разы, system-wide - категорически дурная идея в общем случае. Ну то-есть, как я уже сказал - можно печатать и 1 рукой. Но медленнее и вообще неудобно.
> 2) С SSE намного быстрее работает код для RAID5/6 и шифрование, например. Буквально кипа модулей ядра при возможности юзает самые современные наборы инструкций.вы точно уверены в своих словах?
AES/CRC32 и прочие подобные инструкции - не являются SSE subset - это вполне себе отдельный кусок cpu.
И для детектирования используются cpuid флаги отнюдь не SSE. Вон ребята писали реализацию crc32/crc32c для интела - так что плавали знаем.> И да, знаешь, там кроме всего прочего в dmesg пишется результат бенчмарков. И я имею отметить что от новых инструкций есть толк: самые забористые реализации алгоритмов на новейших командах могут делать старые SSE в несколько раз. А без SSE - вообще сталинград.
на счет рейда - намного быстрее SSE бегает IO AT - вполне себе аппаратно считает checksum/PQ - только имеет свои проблемы и не очень рекомендовано к использованию. А так - 2.5GB/s через него прокачать можно - выше правда проблемно.
> А просадить половину криптографии и кода рэйдов в разы, system-wide - категорически дурная идея в общем случае. Ну то-есть, как я уже сказал - можно печатать и 1 рукой. Но медленнее и вообще неудобно.
Если ты объяснишь зачем в KVM внутри рейд. И почему не расположить диски от KVM на рейде в host системе.
> вы точно уверены в своих словах?Я уверен что я в состоянии прочитать dmesg и увидеть где самые забористые бенчи :)
[ 3.803854] raid6: sse2x4 10175 MB/s
[ 3.803876] raid6: using algorithm sse2x4 (10175 MB/s)
[ 3.803880] raid6: using ssse3x2 recovery algorithm
[ 3.804370] xor: automatically using best checksumming function:
[ 3.844856] avx : 10181.000 MB/sec> AES/CRC32 и прочие подобные инструкции - не являются SSE subset -
Они, конечно, не являются, но упомянутый компилер и их собрать не сможет, так что в этом плане - однофигственно. И вон там выше и пример того как SSE-вариант победил в бенче опять же.
Подобные вещички без SSE и AVX почему-то в несколько раз тормознее. А этот код - совсем не то место где хотелось бы налететь на тормоза.
> это вполне себе отдельный кусок cpu.
Да какая с точки зрения програмеров и компилеров разница? Все-равно авно кастомный асм надо в парочке модулей заковырять как вставки. Что в случае SSE, что в случае AVX/AES/....
> И для детектирования используются cpuid флаги отнюдь не SSE. Вон ребята писали
> реализацию crc32/crc32c для интела - так что плавали знаем.Да какая разница? С точки зрения програмера и компилера - индифферентно в нашем контексте поддержки таких выкрутасов со стороны компилера.
> на счет рейда - намного быстрее SSE бегает IO AT - вполне
> себе аппаратно считает checksum/PQ - только имеет свои проблемы и не
> очень рекомендовано к использованию. А так - 2.5GB/s через него прокачать
> можно - выше правда проблемно.Ну вон выше был бенчмарк. С SSE и AVX оно на моем десктопе 10Гб в секунду могет. Понятно что это больше теоретические цифры, но без этих улучшайзеров скорость обваливается в несколько раз. Я туго себе представляю как можно обмолотить 10 гиг в секунду без оптимизнутого по самые уши ассемблера в критичных местах.
Вообще, стараниями интела и прочих - криптографию и тому подобные вещи в ядре очень сильно оптимизируют нынче и с новыми наборами инструкций оно реально выигрывает. Местами довольно сильно. Интелу то понятен интерес - так привлекательность новых чипов повышается. С другой стороны - странно если аппаратная фича есть а софт ей не пользуется. Вот теперь - и пользуется и выигрывает по полной программе.
> Если ты объяснишь зачем в KVM внутри рейд. И почему не расположить
> диски от KVM на рейде в host системе.Ну так вот на хосте оно от SSE и выиграет, фигле. Я вообще нигде не говорил что в KVM виртуалке надо RAID. Это ваша больная фантазия разбушевалась, я тут не при чем :).
> Я молча развожу руками... Может продемонстрируете?"Его можно собирать всем, чем угодно." с точки зрения лицензии тулчейна и его обвязки. Это никак не повлияет на требования к лицензированию программ в userland-е.
>> Как раз сборка ядра - это совсем не показатель. Его можно собирать
>> всем, чем угодно.
> Я молча развожу руками... Может продемонстрируете?icc, open64, tcc
>> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.
> Я не в курсе деталей этой истории, но лично мне ничего удивительного
> в ней не видится. Полагаю, что сперва Столман & K решилиСпасибо, что спросили! :)
Исключение про рантайм там было чуть не с созданья мира.
"Просто" при переходе на GPLv3+ его не пофиксили под все [новые] "крайние" случаи. Это было сделано _сразу же_ по обнаружении (=рипорте о) проблемы, в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.
Вот кусок из дебиановского /usr/share/doc/libstdc++5/copyright из libstdc++5_3.3.6-20.
The libstdc++-v3 library is licensed under the terms of the GNU General
Public License, with this special exception:
As a special exception, you may use this file as part of a free software
library without restriction. Specifically, if other files instantiate
templates or use macros or inline functions from this file, or you compile
this file and link it with other files to produce an executable, this
file does not by itself cause the resulting executable to be covered by
the GNU General Public License. This exception does not however
invalidate any other reasons why the executable file might be covered by
the GNU General Public License.
>>> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.
>> Я не в курсе деталей этой истории, но лично мне ничего удивительного
>> в ней не видится. Полагаю, что сперва Столман & K решили
> Спасибо, что спросили! :)
> Исключение про рантайм там было чуть не с созданья мира.
> "Просто" при переходе на GPLv3+ его не пофиксили под все [новые] "крайние"
> случаи. Это было сделано _сразу же_ по обнаружении (=рипорте о) проблемы,
> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.вы серьезно верите что поменяв лицензию - народ не задумывался о том что менять надо и linking exception?
юристы типа "забыли"? вам самому не смешно? вы уверены что больше ничего не забыли такого что выйдет боком через N лет ?Ну да - а пофиксили когда их макнули в это дерьмо - что так дела не делают.. а если бы не ткнули - так бы и работало все.
>> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.
> вы серьезно верите что поменяв лицензию - народ не задумывался о томМартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала.
Святой отец, б., "веруешь ли", да, "веруешь ли".
>>> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.
>> вы серьезно верите что поменяв лицензию - народ не задумывался о том
> Мартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала.
> Святой отец, б., "веруешь ли", да, "веруешь ли".а по теме сказать чего-то есть? я вижу только веру в великого..
> а по теме сказать чего-то есть? я вижу только веру в великого..Да какая там вера? Обычный жирный троллинг всяких глупых личностей. Они, кстати, ведутся. Хоть и жирнота, казалось бы. Все-таки Митрофанов - талант. Так жирно потроллить чтобы на это какой-то лузер еще и купился - это талант иметь надо :)
> Я в курсе. Но из embedded движков логичнее выбрать SQLite,Как по мне я вижу минимум 2 причины НЕ выбирать его:
1) SQL априори тормозной и его профайлинг может местами превратиться в полный головняк.
2) Бодаться с SQL иньекциями нравится не всем.В базу key-value такого плана заиньектить левак невозможно. Поэтому базы key-value по своему прекрасны. И никак не заменяются скулайтом, при всем уважении к оному.
То-есть, скулайт в принципе не сможет предоставить сравнимую производительность + отсутствие проблем с иньекциями в SQL запросы от всяких "бобби тэйблсов". А превращать полпрограммы в фильтр т.к. "злоумышленник может унести солонку, назвавшись Бобби Тэйблсом" совершенно не прикольно.
> движок легко позволяет сэмулировать key-value storage :)
Вот только скорость работы что-то не эмулируется. И иньекции станут отдельным пунктом головняка у програмера.
> В базу key-value такого плана заиньектить левак невозможноИ в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set.
> Вот только скорость работы что-то не эмулируется.
А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать.
> И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set.Ты издеваешься или как? Можно взять готовое решение которое работает быстро и безграбельно, а можно др@читься с выписыванием костылей самому + просесть в скорости. Нафиг надо такое "счастье"?
В нормальном виде сие должны были делать по людски разработчики скулайта, предоставив простое и низкоуровневое апи к его фактической реализации хранилища. Но это не было их целью, как соедует из названия. У них SQL головного мозга и баста. Если тебе нравится забивать гвозди микроскопом - флаг тебе в руки делать key-value из скулайта. А мне если уж AGPL так сильно дорогу перейдет, я какой-нить токийский кабинет возьму скорее.
И да, обычно в таких базах можно выбирать довольно низкоуровневые параметры стоража, которые иногда довольно сильно роялят. В частности - хэш-таблица, б-дерево, etc. Они разные по свойствам и в зависимости от ситуации - оптимальнее или так, или эдак. А в скулайте такое вообще хрен выберешь вообще.
> А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать.
Я не собираюсь бросать все и подрываться изучать новый ЯП (SQL) на уровне супергуру который умеет запросы профайлить. Тем более что там IIRC нет относительно низкоуровневых опций управления логикой стоража на уровне самых основ технологий хранения. А иногда удачный выбор таких опций может скорость в разы поднять. На скулайте придется пыхтеть в разы больше, а скорость будет в разы ниже.
> Ты издеваешься или как?Да нет. Мне просто ехать, а не шашечки.
>> Ты издеваешься или как?
> Да нет. Мне просто ехать, а не шашечки.ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB ?
> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB ?Вы таки серьезно считаете, что в том же SQLite на бакенде текстовый файл со строчками INSERT INTO Table VALUES (1, "John"), (2, "Doe") ?
Нет, там конечно бинарный стораж, но простой и быстрой дорожки его дернуть не дадено, равно как и управлять его базовыми свойствами.А общаться с ним через призму парсера скуля - совершенно отдельная история. Парсер потратит немало времени на разбор конструкции и не факт что это будет оптимально.
С другой стороны хорошая база ключ-значение как правило укладывается в всего 2 дисковые операции на извлечение записи + минимальная нагрузка на проц.
> Парсер потратит немало времени на разбор конструкции и не факт что
> это будет оптимально.Два слова: "prepared statements" - о чём-нибудь говорят?
>> Парсер потратит немало времени на разбор конструкции и не факт что
>> это будет оптимально.
> Два слова: "prepared statements" - о чём-нибудь говорят?говорит - что исполнение байт кода - всегда дольше чем просто поиск по базе key-> value.
Кстати как там с SQLite с поддержкой транзакционного стораджа?
> говорит - что исполнение байт кода - всегда дольше чем просто поиск
> по базе key-> value.Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными. В остальных случаях накладные расходы будут несущественны.
Не забывайте, что у KV обычно всё атомно плохо с индексацией и произвольным поиском. Плюсы от возможности вести поиск по связям и наборам полей могут и перевесить минусы от наличия разборщика запросов. Не везде, естественно.
Во всяком случае, Subversion уже использует SQLite в клиентской части. Очевидно, осознали плюсы.
> Кстати как там с SQLite с поддержкой транзакционного стораджа?
А там иных не бывает... огромная проблема SQLite - необходимость блокирования всего файла при записи. Коммиты у SQLite атомарные, поэтому с конзистентностью всё более-менее. Не хуже, чем у BDB, во всяком случае.
> Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными.Ага. Особенно если нужно обработать данные из таблички с парой-тройкой десятков-сотен миллионов записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.
>> Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными.
> Ага. Особенно если нужно обработать данные из таблички с парой-тройкой десятков-сотен миллионов
> записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.не надо издеваться с детей :-) вот к примеру filldir() вполне себе выполняется внутри inner loop у dx dir аналогом которого является bdb и таких примеров чуть более чем дофига..
> не надо издеваться с детей :-) вот к примеру filldir() вполне себе
> выполняется внутри inner loop у dx dir аналогом которого является bdb
> и таких примеров чуть более чем дофига..Ну... ручки-то они - вона какие...
Вот, лакмусовая бумажка на крап-дезигнеров сработала. Если у вас случилась ситуация (shit happens, yeah), что вам надо из KV более одного раза за время жизни с последнего апгрейда вот так вот выгрести и обработать сотню миллионов записей - "поздравляю, Шарик, вы балбес"... выбор KV для задачи не то, что не оправдан, а вообще симптоматичен.
> задачи не то, что не оправдан, а вообще симптоматичен.Тем не менее, справедливости ради - сиквельная будет вычитывать записи ничуть не хуже самопала. А при шит дизайнере с select * from, столь типичном для скрипткиддисов... - скульная база натурально все сотни миллионов записей будет лопатить ничуть не хуже.
Грамотно юзать скуль и понимать во что по факту оно будет трансформировано (дисковая активность, etc) умеет сильно немного народа - это отдельный класс крутых DBA/опытных SQL программеров, в общем свой заводик по производству ракет, со своим рокетсайнсом и инженерами. Вот так с наскока это взять вообще не варинт. Грамотно юзать k/v на порядок проще. Просто потому что он примитивный.
> записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.Если тебе приходится это делать с K/V - ты что-то делаешь не так. Совсем не так.
>> говорит - что исполнение байт кода - всегда дольше чем просто поиск
>> по базе key-> value.
> Если обращения к KV store в inner loop - да, разница будет.
> Но обычно обращения к БД во внутренних циклах - крайне плохой
> тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными.
> В остальных случаях накладные расходы будут несущественны.
> Не забывайте, что у KV обычно всё атомно плохо с индексацией и
> произвольным поиском. Плюсы от возможности вести поиск по связям и наборам
> полей могут и перевесить минусы от наличия разборщика запросов. Не везде,
> естественно.Плохо с произвольным поиском по ключу?! а индексация там к чему?
А о словах secondary key - вы что-то слышали?
> Во всяком случае, Subversion уже использует SQLite в клиентской части. Очевидно, осознали
> плюсы.Видимо это должно служить большим показателем.. Не подскажете почему? при этом у mysql был bdb сторадж. http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html
но я не разу не слышал о SQLite сторадже для MySQL.
не подскажете почему?>> Кстати как там с SQLite с поддержкой транзакционного стораджа?
> А там иных не бывает... огромная проблема SQLite - необходимость блокирования всего
> файла при записи.ЭЭ.. позвольте - если там есть нормальные транзакции - то там не надо блокировать весь файл.
Так и запишем - транзакций нету.> Коммиты у SQLite атомарные, поэтому с конзистентностью всё
> более-менее. Не хуже, чем у BDB, во всяком случае.у BDB - можно делать комиты в несколько таблиц внутри одной транзакции без необходимости лочить базы.
Как видимо это явно "лучше".
> Два слова: "prepared statements" - о чём-нибудь говорят?Здравый смысл и понимание алгоритмов говорят мне что лукап по b-дереву или хэш-таблице априори быстрее чем нечто аналогичное + пакости от парсера невъ...нного языка и вагон костылей для их воркэраундинга.
Но ты в своем праве делать из сиквельной базы key-value. Но лично я не понимаю в чем пойнт сначала сильно усложнить себе жизнь, сначала донавесив поверх хранилища парсер, а потом героически воевать с ветряными мельницами, пытаясь отделаться от его проблем, чтобы в результате ... получить нативное представление сущностей в хранилище? Да ты больной. Проще сразу не навешивать парсер чем воевать с его фирменными граблями типа тормозов, иньекций и прочих радостей жизни.
Ты так и не понял сути. Основная проблема - не в том, что нет KV на замену, а в том, что KV пихают даже туда, где он в принципе убыточен.А речь изначально шла о том, что в ряде проектов BDB можно заменить на embedded SQL/embedded NoSQL. Чего накинулся - непонятно.
> даже туда, где он в принципе убыточен.Такое наверное бывает, но это можно делать из чувства мазохизма разве что. Это скорее SQL нынче пихают даже туда где он нафиг не упал и только все портит. Вот вы - яркий показатель, btw.
> А речь изначально шла о том, что в ряде проектов BDB можно
> заменить на embedded SQL/embedded NoSQL.Можно != нужно. Сам по себе NoSQL термин - вообще ни о чем. BDB тоже NoSQL. Хотя и SQL там в принципе есть, правда я ни разу не видел чтобы им кто-то пользовался, но потенциально - можно :).
> Чего накинулся - непонятно.
То что довольно странно предлагать самосвал как замену микроавтобусу, с аргументом "если как следует поорудовать автогеном, можно кузов отпилить и заменить на салон микроавтобуса".
Спору нет - все это можно. Только рассматривалось целевое использование k/v ака быстрый и простой доступ к записям, возможно в достаточно большом количестве. Там SQL не только нафиг не упал но и все испортит. А то что кто-то мог заюзать свой микроавтобус для перевозки песка из карьера - ну так кто ему доктор?
> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
> BDB ?Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того, что работа с BDB - не основная операция.
>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
>> BDB ?
> Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того,
> что работа с BDB - не основная операция.у кого как :-)
> у кого как :-)Ну, у юнит-тестов BDB все, конечно, иначе...
> Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того,
> что работа с BDB - не основная операция.А это как бы весьма зависит от. Такие базы ставят там где скорость работы с базой все-таки интересовала. При этом сознательно идут на упрощение абстракций и их примитивизацию в пользу скорости работы + можно не париться экранированием (которое для больших объемов данных опять же тормознет все). Все-равно заиньектить в базу принимающую любые данные как ключ и значение технически невозможно.
> Такие базы ставят там где скорость работы с базой все-таки интересовала.Особенно в том же SVN, агаугу. Или в PAM. Там и SQL нахрен не впёрся, конечно, но в целом от скорости работы с самим форматом базы там ничего не меняется - не там основная нагрузка.
> Особенно в том же SVN, агаугу.Ой, как они им пользуются - я без понятия. Не интересуюсь некромансией. В git например свой самопальный кастомный формат хранения объектов везде, т.к. все это очень чувствительно к скорости.
> Или в PAM.
Как бы в таких применениях ситуация бывает разной. Какой-нибудь контроллер домена например может обслуживать десятки тысяч авторизаций в секунду. И я не вижу ни одной валидной причины по которой PAM имел бы право умирать под такими нагрузками. Лучше пусть запас производительности будет чем наступит ж@па.
> Там и SQL нахрен не впёрся, конечно, но в целом от скорости работы с
> самим форматом базы там ничего не меняется - не там основная нагрузка.Зато прилетевший на что-то типа контроллера домена скуль иньекшн от бобби тэйблса энтерпрайзникам точно понравится :). Ибо раздестроить нечто типа активной директории или ее аналога 1 запросом - сказочная мечта любого кулхацкера :).
> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
> BDB ?Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В SQL-based движках в основном всё те же btree :) на подложке.
А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на большие расстояния. Да и просто практичнее в плане удобства. Доехать-то доедешь, но за@#$шься прилично.
Там, где структура данных достаточно простая, и отношение объема данных к объёму единственного ключа максимально - лучше KV не придумать. Где посложнее - использование KV или прямых методов доступа к сторейджу выльется в феерические костыли, которые уже давным-давно сделаны в реляционных движках, и сделаны лучше.
Вопрос в применимости. Когда-то embedded-движков RDB не было, и все юзали что попало, изобретая велосипеды для поиска в KV-сторейдже к примеру. Сейчас их вагон, и отказываться от удобства - тупо.
>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
>> BDB ?
> Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В
> SQL-based движках в основном всё те же btree :) на подложке.Замечена попытка ухода в сторону. Вами был выдвинут тезис что реализация KV стораджа средствами SQLite по меньшей мере не медленее чем BDB а то и быстрее. Вот отсюда и вопрос - вы серьезно считаете что скорость выполнения предкопилированых sql запросов в sqlite будет дотягивать до скорости поиска по b-tree для BDB ?
> А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на
> большие расстояния. Да и просто практичнее в плане удобства. Доехать-то доедешь,
> но за@#$шься прилично.Зависит от загруженности города. Я знаю много городов где на велосипеде доехать быстрее.
> Там, где структура данных достаточно простая, и отношение объема данных к объёму
> единственного ключа максимально - лучше KV не придумать. Где посложнее -
> использование KV или прямых методов доступа к сторейджу выльется в феерические
> костыли, которые уже давным-давно сделаны в реляционных движках, и сделаны лучше.Может вы забыли что для правильного использования SQL надо приводить к НФ 3? а тогда большой разницы с поиском по ключу в KV не будет. хотя да.. современная молодежь забывает о нормальных формах БД.
> Вопрос в применимости. Когда-то embedded-движков RDB не было, и все юзали что
> попало, изобретая велосипеды для поиска в KV-сторейдже к примеру. Сейчас их
> вагон, и отказываться от удобства - тупо.Да да. А перегружать задачи не нужной функционостью - это ооочень правильно. И терять в скорости тоже..
как это похоже на современных программистов - которые вырезают гланды автогеном..
> Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В
> SQL-based движках в основном всё те же btree :) на подложке.Вот только сперва донавесить парсер, а потом путем длительной борьбы задеградировать его до "почти b-дерева" - бессмысленно и беспощадно. Куча времени будет убита ни на что!
- Придется изучить SQL.
- Придется изучить сколько времени и где тратится.
- Придется очень хорошо раздуплять как оно план выполнения кроит и прочая.
- И как это потом трансформируется в дисковую активность.
- И как это "хакнуть" чтобы этот бредогенератор минимизировал свои операции и вообще интерференцию.
- Придется делать экранирование.
- Итоговая скорость даже в самом идеальном случае будет несколько хуже. В реальном случае, с разумными затратами сил, без месяца профилировки и войны с парсером/планировщиком выполнения - оно скорее всего сольет в несколько раз.> А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на
> большие расстояния.При всем уважении, автомобиль не заменяет велосипед.
> При всем уважении, автомобиль не заменяет велосипед.В 1% случаев - не заменяет. Попытки проехать на велосипеде от Москвы до хотя бы СПб - ну чего, флаг в руки.
> В 1% случаев - не заменяет. Попытки проехать на велосипеде от Москвы
> до хотя бы СПб - ну чего, флаг в руки.Да фигня вопрос! Кладем в багажный отсек поезда/самолета и едем :).
> Да нет. Мне просто ехать, а не шашечки.Мне тоже. И мне совершенно не улыбается идея опилить сначала самосвал до легковушки а потом еще и удивляться - ой, а чего это он даже по идеальному шоссе выше 80 км/ч вообще никак? :)
Я согласен, что для KV лучше использовать именно KV сторейджи. Но в приличном ряде случаев, а особенно там, где для KV применялся BDB - разница вряд ли будет ощутимой. Плюс вполне возможно, что польза/выигрыш от перехода на SQL с индексами и произвольными выборками будет больше, чем от собственно архитектуры KV.PS. Очепятался.
> Я согласен, что для KV лучше использовать именно KV сторейджи. Но в
> приличном ряде случаев, а особенно там, где для KV применялся BDB
> - разница вряд ли будет ощутимой.KV обычно применяется тем где надо быстро лопатить много записей в примитивном виде. Скуль в этом случае ничего кроме головняка вообще не даст.
> Плюс вполне возможно, что польза/выигрыш от перехода на SQL с индексами
> и произвольными выборками будет больше, чем от собственно архитектуры KV.В KV априори есть полный индекс по ключу, по другому оно просто работать не умеет :). Там негде выигрывать. Это и так одна из наиболее быстрых опций - непосредственный лукап в стораже без всякого промежуточного балласта. Скулю там негде выиграть по скорости, by design. По крайней мере в key-value применениях.
Скуль имеет смысл для навороченных иерархий с таблицами и прочая - на KV придется сделать то же самое но через тот еще зад и самому. Но если KV уже поюзан - значит задача совсем не о том была.
> KV обычно применяется тем где надо быстро лопатить много записей в примитивном
> виде. Скуль в этом случае ничего кроме головняка вообще не даст.При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.
> При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.а это называется «мы узнали модный баззворд». если в задаче часто требуется какое-то навороченое фильтрование, для которого никак не получается вывернуться, зашив нужную информацию в ключи, то авторы промахнулись с инструментом.
> При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.Да вы, я так смотрю, эксперт по забиванию гвоздей микроскопом. Вы умеете сватать и скуль туда где он не уперся, и kv там где с ним сложно.
Тем не менее, некоторые k/v умеют сортировку записей и/или выборку диапазонов, если уж на то пошло. Насколько оно там подойдет в конкретном случае - вопрос номер два, смотреть надо. Но если подойдет - это будет круто и быстро, ибо все это на уровне нативного представления данных в стораже.
> Я в курсе. Но из embedded движков логичнее выбрать SQLite, если конечно
> параллелизм на записи не требуется.LMDB: http://symas.com/mdb/
> LMDB: http://symas.com/mdb/mmaped -> на 32-бит платформах лимитирована 4Гб. Это фэйл.
>> LMDB: http://symas.com/mdb/
> mmaped -> на 32-бит платформах лимитирована 4Гб. Это фэйл.скажи, что у тебя за база размером в терабайты? и что за приложение, которое требует, чтобы ко всем этим терабайтам был рандомный доступ всегда? и почему там key/value, когда такие базы явно требуют более сложных выборок?
короче говоря, у тебя или понты ради понтов, или хреновое проектирование и неверно выбраный инструмент.
алсо, если ты ворочаешь такими объёмами данных, то почему у тебя x86? наверняка там сервер с кучей RAM, и лимитировать одну задачу четырьмя гигабайтами как-то очень глупо.
> скажи, что у тебя за база размером в терабайты? и что за
> приложение, которое требует, чтобы ко всем этим терабайтам был рандомный доступ
> всегда? и почему там key/value, когда такие базы явно требуют более сложных выборок?С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком примитивной и заменишь свою файловую систему на SQLную базу, ога :)
> короче говоря, у тебя или пoнты ради пoнтов, или хрeновое проектирование и
> неверно выбраный инструмент.Короче говоря, это просто ничем не обоснованный буллшит. Простая и быстрая база вполне может катить для применений где хранится сколько-то гб данных. Отличный пример таких баз - файловые системы, которые по сути оно самое и есть. Ну разве что заоптимизировано под свои специфичные нужды. А по общей логике - напрашивается чтобы тебя потроллить этим применением за излишне generic'овые высказывания :).
> алсо, если ты ворочаешь такими объёмами данных, то почему у тебя x86?
Алсо, я могу прицепить 2-терабайтный винч к вон той 32-битной ARMовской платке по sata. Ничему не противоречит. А вот какой-то совершенно идиoтский лимит нарисовавшийся на ровном месте - двигуну совсем не в плюс.
Не, в целом смотрится любопытно, но вот это свойство все портит. Увы, я такое классифицирую как defective by design.
> С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком
> примитивной и заменишь свою файловую систему на SQLную базу, ога :)MS уже пыталась. Идея, кстати, неплоха, но опять же - не стоит ее везде лепить - только там, где нужен поиск по хреновой туче нечетких критериев.
> MS уже пыталась.Но зафэйлили. И если уж на то пошло, у MS есть собственный весьма забористый ESE storage engine который они никуда выкидывать не собираются и он больше ориентирован на простую но быструю работу нежели на навороты а-ля скуль.
Этот движок используется такими "незначительными" сущностями как active directory и exchange. При том что у MS, заметь, есть и сиквел-сервер, даже у MS хватает ума не впихивать это там где надо натурально быстрый доступ к базе без переусложнений которые бы реально потребовали скуль.
Я конечно понимаю что если упереться рогом в свой долбаный скуль то кажется что мир крутится вокруг него. Но если разуть глаза - можно обнаружить немало интересных фактов, отличающихся от вашего представления о серебряных пулях.
> Идея, кстати, неплоха, но опять же - не стоит ее везде лепить - только там,
> где нужен поиск по хреновой туче нечетких критериев.В конечном итоге оказалось проще навесить внешний индексатор. И там тоже вроде как никаких скулей не пользуется. Вообще поражают потуги всучивать скуль во все щели, даже туда где он нафиг не уперся и создает только кучу проблем на ровном месте.
> При том что у MS, заметь, есть и сиквел-сервер, даже у
> MS хватает ума не впихивать это там где надо натурально быстрый
> доступ к базе без переусложнений которые бы реально потребовали скуль.Имхо просто переделывать некому пока. А насчет SQL - он у них даже в WMI представлен весьма себе неплохо - где он имхо совершенно не нужен.
> В конечном итоге оказалось проще навесить внешний индексатор.
Да и работает он... как внешний индексатор... Многие функцию "поддержки поиска" тупо отключают сразу после инсталла, потому что именно так и реализован.
> Имхо просто переделывать некому пока.Написать SQL сервак есть кому, написать ESE storage есть кому, а переделать некому? Как-то слишком притянуто за ущи звучит. Тем более что ESE и их SQL серверу вроде примерно одинаково лет, плюс-минус лапоть. Просто MS на заре своего развития умудрился набрать вменяемых спецов а не придурков с горящими глазами, лихо забивающих любимом микроскопом гвозди любого калибра. Поэтому с тех времен у них остался ряд достаточно продуманных решений, сделанных специалистами, с задействованием головы. Поэтому кроме всего прочего все это хозяйство работает с достаточно приличной скоростью на достаточно больших объемах данных, что актуально ынтырпрайзникам с AD о десятках миллионов объектов и многими гигазами почты. И даже с учетом безбашенного управления они еще все-таки не все полимеры проср@ли. Вот конкретно эти 2 до сих пор без лобовой замены пока. При желании заменить можно, но возни - будет. И не факт что будет работать так же хорошо. Одна из причин почему MS еще не послали во всех энтерпрайзах, несмотря на геморные условия лицензирования.
> А насчет SQL - он у них даже в WMI представлен весьма себе неплохо - где он имхо
> совершенно не нyжен.Вот про это - ничего не знаю. Я расписывался лишь за то о чем более-менее в курсе.
> Да и работает он... как внешний индексатор... Многие функцию "поддержки поиска" тупо
> отключают сразу после инсталла, потому что именно так и реализован.Неа, отключают просто потому что нафиг не упало - те у кого есть мозг обычно и так знают что у них и где лежит. Зачем мне индексатор, если я и так структурую хранение информации и могу быстро найти ее сам? А индексатор по любому будет жрать ресурсы - он по любому должен файлы парсить. Чудес не бывает.
redis embedded решает
> redis embedded решает
Чемпионат по громким баззвордам объявляется открытым. Давайте еще какую-нить nosql фигню на яве притащим? :)
Visual Basic 6 nosql
> Visual Basic 6 nosqlVB старье. Так что хиленькая попытка, увы :). Сейчас в моде питон. Ну или там руби. Или какой там еще брейнфак с VB-подобным синтаксисом я забыл?
Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB :DDКал ведь ещё тот...
> переход на agpl3 вами, последовательными "сторонниками свободного по", должен быть одобренВот это и был бы условный рефлекс на недостаточную информацию.
Ну вот, теперь мой комментарий без развёртывания выглядит как ответ на его брата.
> Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB
> :DD
> Кал ведь ещё тот...очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили) может выполняться в kernel space.. + в качестве примеров идет чуть ли не кусок журналируемой файлухи.. - очень не плохой вариант.. Вы видимо готовить его не умеете?
> очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили)
> может выполняться в kernel space.. + в качестве примеров идет чуть
> ли не кусок журналируемой файлухи.. - очень не плохой вариант..Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут, так даже интереснее.
> Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут,
> так даже интереснее.Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные апи. И документировано неплохо.
Для типового проекта на ее базе 99% функционала просто не нужно.
> Для типового проекта на ее базе 99% функционала просто не нужно.В любом случае, базы данных, даже простые - относительно навороченный и сложный кусок знаний, который типичному прикладнику вгружать в свою голову совершенно не с руки.
> В любом случае, базы данных, даже простые - относительно навороченный и сложный
> кусок знаний, который типичному прикладнику вгружать в свою голову совершенно не
> с руки.Типичный прикладник BDB за пять километров стороной обходит. И правильно делает, кстати.
> Типичный прикладник BDB за пять километров стороной обходит. И правильно делает, кстати.Вот только я с этой базой именно на примере нужной мне прикладухи и познакомился. Там вылезли грабли, и по этому поводу меня ждала целая экскурсия в мир BDB и даже ее внутренностей немного. В целом увиденное понравилось. Хорошо написана дока, понятно как юзать. Фич прилично. Все логично сделано.
Да, а самое приятное - разработчики из sleepycat помогли умахать грабли (оказавшиеся платформо-специфичными) - буквально не более 2 дней на переписку и пришло понимание места где рукоятка грабель внезапно встречается со лбом. При том ни цента за такой годный саппорт не запросили + запатчили грабли в апстриме и выкатили новую версию довольно оперативно.
Не знаю, насколько они испортились после покупки ораклем, но до этого с ними и их базой было вполне приятно иметь дело.
Из того что НЕ понравилось: оно довольно большое и фич там на порядок больше чем обычно надо от key-value, добавляет довольно много кода. Потом они даже SQL сделали. И скорость работы не чемпионская в своем классе.
> Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная
> и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные
> апи. И документировано неплохо.я уже как-то даже подустал: LMDB: http://symas.com/mdb/
> я уже как-то даже подусталМилорд, в этом обсуждении нужно больше ссылок на LMDB.
> Милорд, в этом обсуждении нужно больше ссылок на LMDB.нужно. потому что куча народу о ней не в курсе. и не все подписаны на обновления, так что некоторые анонимусы, которым оно будет интересно, могут и пропустить.
> нужно. потому что куча народу о ней не в курсе.Mmaped -> must die. Нафиг надо kv-базу с лимитом на 4Гб. Шутка юмора не понята.
> Mmaped -> must die. Нафиг надо kv-базу с лимитом на 4Гб. Шутка
> юмора не понята.см. выше.
впрочем, я готов побиться об заклад, что ты не только не понимаешь места и способы применимости k/v, но и никогда не работал с реально большими объёмами данных. поэтому твое мнение — из разряда «я админ локалхоста, я точно знаю, как надо админить парк из 9e+3 машин!»
> впрочем, я готов побиться об заклад, что ты не только не понимаешь
> места и способы применимости k/v,Какой высокопарный апломб. Иди расскажи разработчикам файловых систем с верхним лимитом на экзабайты какие они лохи :). А то они тоже что-то маппят путь к файлу в данные файла. По сути подвид K/V вполне себе. Хоть и оптимизированный под специфичное применение. Ну ты сам нарывался своими generic заявами за "k/v вообще" чтобы тебя так боднули. Ты и сам такие подъ...ки любишь вроде. А тут моя очередь :P.
Как раз k/v прекрасны в том числе и
1) Низким оверхедом.
2) Высокой скоростью даже при диком количестве записей.У хэш-таблиц например вообще время работы - O(1). Замечательная штука чтобы туда вагон записей сгрузить.
> Как раз k/v прекрасны в том числе и
> 1) Низким оверхедом.
> 2) Высокой скоростью даже при диком количестве записей.Именно. И это нужно там, где это нужно. В остальных случаях за использование KV придётся платить изобретанием велосипедов и колёс. К сожалению, очень часто KV юзают там, где не стоило бы.
> Именно. И это нужно там, где это нужно.Вообще случаев где key/value хватит - довольно много. Если не заморачиваться искусственным переусложнением сущностей.
> В остальных случаях за использование KV придётся платить изобретанием
> велосипедов и колёс.Вот только в насоветованных вами решениях изобретение великов типа экранирования и прочая - вообще сразу подразумевалось по дефолту для ВСЕХ случаев.
> К сожалению, очень часто KV юзают там, где не стоило бы.
SQL не менее часто юзают где он нафиг не упал. А еще - именно грамотно им пользоваться умеет очень мало народа. Поэтому тут вам и вагон скуль-иньекций в каждой дырке, и адские тормоза казалось бы простых как топор операций, и дикие прелести жизни.
Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами. Они там 126 столбцов завели. И хранили, итить, цвет шрифта как отдельную колонку в таблице. В k/v они бы по крайней мере за...сь так извращаться и поневоле пришли бы к более разумным решениям :). Ах да, при чем тут sql.ru? Мускул при попытке создать ЭТО - сдуревал и выдавал ошибку, разумеется :)
> Вот только в насоветованных вами решениях изобретение великов типа экранирования и прочая
> - вообще сразу подразумевалось по дефолту для ВСЕХ случаев.Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный код при правильной его организации. Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано), то скорее всего все запросы изначально будут в виде prepared statements, и никакого явного экранирования не потребуют.
> Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами.
В .ru вообще много примеров использования разных вещей безмозглыми существами... но это ни о чем не говорит.
> Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный
> код при правильной его организации.Тем не менее, это дополнительные действия. Если данных много, их экранирование/деэкранирование может занять вполне заметное время. Хороший k/v вообще хранит любые данные. Что означает отсутствие таких проблем by design. Намного лучше когда дизайн failsafe сам по себе, да еще и скорость не просядет лишний раз.
> Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано),
С таким же успехом можно говорить и о обратном переходе там где SQL запихнули "потому что модный buzzword же". И тут вдруг ВНЕЗАПНО до некоторых стало доходить что NoSQL может быть инересной опцией в плане скорости :). В основном потому что там геморно делать неоптимальные запросы.
> то скорее всего все запросы изначально будут в виде prepared statements, и
> никакого явного экранирования не потребуют.Не, куча допущений - это здорово, конечно, но я не вижу - что даст такой маневр в общем случае кроме лишнего головняка и тормозов. SQL достаточно сложный ЯП, грамотно делать запросы на оном умеет очень небольшое количество народа. А чтобы оно еще и работало со скоростью хоть немного похожей на оную у key-value баз - это вообще рокетсайнс.
Я конечно понимаю рвение везде пихать SQL, но обычно как раз это приводит к тому что его пытаются сосватать даже туда где он нафиг не упал. А потом начинаются удивления - "ой, как это - файрфокс начинает тормозить если вы много сайтов посетили?!". И догадайтесь, блин, во что оно уперлось. В сиквельную базу, итить. Во как.
>> Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами.
> В .ru вообще много примеров использования разных вещей безмозглыми существами... но это
> ни о чем не говорит.Хорошо, я могу и иной пример. А вот в амарок2 активно сватали мускуль. Я например совершенно не понял зачем мне в системе здоровенный демон от навороченной базы и просто снес все это безобразие нафиг. Они бы еще пэхэпэ и апач приволокли, блин.
>> Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная
>> и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные
>> апи. И документировано неплохо.
> я уже как-то даже подустал: LMDB: http://symas.com/mdb/О, любопытно. Токийско-киотские кабинеты мне чем-то не понравились, уже даже не помню чем, давно было. А это вроде милое. Не такое милое, как питоновская shelve с её подложками, но всё равно милое. :)
это замена для сишников сотоварищи. нам бидон как-то не в тему будет. собственно, замена именно BDB, потому что у них очень похожие API.а так — ещё hamsterdb есть, например. гуглевый leveldb. tdb из самбы на крайний случай. сотни их.
> собственно, замена именно BDB, потому что у них очень похожие API.Только bdb насколко я помню адресным пространством не лимитирована. А для 32-битных платформ лимит в 4Gb может больно шибануть ручкой грабель в лою.
>> собственно, замена именно BDB, потому что у них очень похожие API.
> Только bdb насколко я помню адресным пространством не лимитирована. А для 32-битных
> платформ лимит в 4Gb может больно шибануть ручкой грабель в лою.если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то делаешь очень неправильно.
> если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то
> делаешь очень неправильно.Жду когда ты себе диск протрешь нулями, а то файловая система тоже маппит ключ "путь и имя файла" в значение "данные файла" :)
> если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то
> делаешь очень неправильно.+100500000000000000000000000000000000000000000000000000000000000000000000
> +100500000000000000000000000000000000000000000000000000000000000000000000А ты уже заменил файловую систему на сиквельную базу? А то микрософтушка что-то вон ниасилил :)
>> очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили)
>> может выполняться в kernel space.. + в качестве примеров идет чуть
>> ли не кусок журналируемой файлухи.. - очень не плохой вариант..
> Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут,
> так даже интереснее.а в чем проблема - они разнесли 2 уровня абстракции - контейнер с транзакциями и журналом и таблицы в этом контейнере. Теперь можно делать что угодно - к слову файловая система (ее часть относящаяся к метаданным) это просто таблицы key->value. Да и данные по сути это дерево которое где-то хранить надо..
> Кал ведь ещё тот...Не согласен. Вполне позитивная либа с позитивными разработчиками. Имел счастье когда-то взаимодействовать с ними, понравилось. Sleepycat был вполне прикольной компанией с весьма приятным народцем. И апи у либы довольно мощное и логичное.
"Умненький Буратино!" (с)
Нередко проще купить лицензию чем готовить код к публикации, ибо "как есть" публиковать просто стыдно ;)
Отличная новость - даже не ожидал от оракла подобного.
Давно пора заставлять народ в массовом порядке переходить на последний версии свободных лицензий. А то, понимаешь, развелось тут халявщиков :)
А вот и обделенные судьбою девелуперы подтянулися.. Ты с какого гита будещь? Комиты есть? А если найду?
> Комиты есть? А если найду?Ой, найди! "Аноним, 19:17 , 07-Июл-13", да?
такую же штуку провернула Canonical со своей Ubuntu Phone. Друзьям - пермиссивная лицензия, всем остальным - GPLv3 :)
> такую же штуку провернула Canonical со своей Ubuntu Phone. Друзьям - пермиссивная
> лицензия, всем остальным - GPLv3 :)Как тонко подметил Мэтью Гаррет, из-за Canonical CLA эта конторка может единолично поменять лицензию на все свои пoделия в любой момент. Поэтому убунтофон должен вызывать закономерное недоверие.
А вот с ядром, например, такой фокус не прокатит - там CLA нет, и нужно согласие всех авторов.
Звонок в целом тревожный ... в ОЧЕНЬ многих продуктах используется BDB.
И OpenLDAP и Subversion и Spamassassin и т.д.
На SQLite перейдут ...
LDAP???
> LDAP???Лдап? С скулайтом? Бобби Тэйблс быстро вам объяснит что вы не правы :)
http://pro-ldap.ru/tr/admin24/intro.html#LDAP vs RDBMS
ldap vs sql - вещи плохо совместимые.
вместо bdb можно разве что какую-нибдь NoSQL с бинарными деревьями.
NoSQL+BTREE? Тогда уж SQL/BTree - классику, ибо снявши голову...
> NoSQL+BTREE? Тогда уж SQL/BTree - классику, ибо снявши голову...А зачем работать с b-деревом через такую жо... ой, то-есть, бутылочное горлышко SQL?
> А зачем работать с b-деревом через такую жо... ой, то-есть, бутылочное горлышко
> SQL?Да я не спорю, можно и с сотней гектаров земли лопатой поработать... но проще взять трактор.
А там, где сотни гектаров нет - и разницы не будет, в общем. Есть трактор - хорошо. Нет - тоже хорошо.
> Да я не спорю, можно и с сотней гектаров земли лопатой поработать...Сам по себе kay-value может прекрасно работать с любым объемом данных. Хоть с терабайтом. Доказано файловыми системами :).
В случае b-дерева скорость O(log(n)), а в хэш-таблицах вообще O(1). Во втором варианте размер вообще не роялит - вытаскивание записи не зависит от размера базы.
> но проще взять трактор.
Если посмотреть на нашего любимого враженьку (у конкурентов надо учиться хорошему) - майкрософтушка при наличии у них в портфолио сиквель сервера который они впаривают при каждом удобном случае, тем не менее допер поюзать для активной директории и эксченжа совершенно другой тип стоража - ESE storage engine. Некую хрень с куда более простым доступом но зато куда более быструю. И таки нормальное инженерное решение им воздалось - у всех остальных и по сей день большие проблемы с эквивалентной заменой что AD что Exchange.
> А там, где сотни гектаров нет - и разницы не будет, в
> общем. Есть трактор - хорошо. Нет - тоже хорошо.Буллшит. Вон майкрософт для кучи гектаров в энтерпрайзе как раз подогнал специализированное двигло где никаким SQL и не пахло, как минмум изначально.
> В случае b-дерева скорость O(log(n)), а в хэш-таблицах вообще O(1). Во втором
> варианте размер вообще не роялит — вытаскивание записи не зависит от
> размера базы.зависит, естественно. как минимум потому, что O(1) — это только в идеале. и база не в астрале хранится.
> зависит, естественно. как минимум потому, что O(1) — это только в идеале.
> и база не в астрале хранится.Тем не менее, если библа обещает 2 дисковые операции - они так и будут 2 дисковыми операциями. Иррелевантно к объему файла. Насколько там ФС окочурится и прочая - вообще оффтопик, ибо проблемы ФС - ну вообще никак не вина БД :)
Тем не менее, сами по себе ФС вон масштабируются на терабайты - и ничего, работает. Нормально вполне вроде.
> Звонок в целом тревожный ... в ОЧЕНЬ многих продуктах используется BDB.
> И OpenLDAP и Subversion и Spamassassin и т.д.Голактеко Опасносте!
Придётся перестать жопить код!
от ГПЛ одни только проблемы.
> от ГПЛ одни только проблемы._AGPLv3+_ и Оракл решают!
+_и
> от ГПЛ одни только проблемы.Проприетарщикам проблемы - юзерам хорошо :)
>> от ГПЛ одни только проблемы.
> Проприетарщикам проблемы - юзерам хорошо :)пока что проблемы начались у debian...
> пока что проблемы начались у debian...Этим уродам проблемы - людям тоже хорошо.
Авось вообще вымрут уроды - тогда мир станет немного чище.
>> пока что проблемы начались у debian...
> Этим уродам проблемы - людям тоже хорошо.
> Авось вообще вымрут уроды - тогда мир станет немного чище.это вы так о debian ?
> это вы так о debian ?Конечно. О ком же еще.
> пока что проблемы начались у debian...Нет. Не начались.
Не веришь? Перечитай ещё раз. Обсуждают только. Это не считается а Debian-е проблемой. ///как и на опеннете
Что-то оракул в последнее время с лицензиями мутит. Что-то затевает нечистый. То мускуль, то еще что.
Мучу, мучу, верчу - долларов побольше хочу...
> Мучу, мучу, верчу - долларов побольше хочу...Верно, чувак. Ораклу кекать на ваши телодвижения. У него цель. Номер один. Кстати, абсолютно верная.
Лишний повод для перехода на более актуальную встраиваемую базу c более вменяемой лицензией. В зависимости от применения: либо sqlite, либо какой-нибудь redis. Альтернатив полно...Вносить существенные изменения в BerkeleyDB бессмысленно, там за десятки лет всё вылизано, как яйца кота (пардон, за натурализм). В рамках своей идеологии BDB уже давно достигла потолка развития...
> лицензией. В зависимости от применения: либо sqlite, либо какой-нибудь redis.При том ни тот ни другой на прямую замену BDB вообще не але. А переписывать полпрограммы - во счастья то. Впрочем, проприетарщикам так и надо, а остальные думается вопрос утрясут :)
BerkeleyDB, пол-программы переписывать? 0_о Вы похоже думаете, что это что-то типа MySQL, да?Если вам для того, чтобы сменить berkeleydb на тот же sqlite, надо переписать пол-программы, то у вас руки не с того места растут и вас к компьютерам подпускать нельзя.
> BerkeleyDB, пол-программы переписывать?а что такого? вот берём — и используем API без очередного дурацкого слоя обёртки.
да-да-да, я знаю, МегаПрограммисты не останавливаются, пока не напишут 13 обёрток над любым апи (а потом добавят ещё несколько — на всякий случай).
> а что такого? вот берём — и используем API без очередного дурацкого
> слоя обёртки.:facepalm: Дай угадаю... лабы по программированию на три балла, не больше, да?
> :facepalm: Дай угадаю... лабы по программированию на три балла, не больше, да?ну, я же не настоящий сварщик, я не считаю, что все проблемы можно решить, добавив ещё один слой Очень Полезной Абстракции.
> ну, я же не настоящий сварщик, я не считаю, что все проблемы
> можно решить, добавив ещё один слой Очень Полезной Абстракции.Да туфта все эти абстракции. Народу нужны нормальные юниксовые костыли! Вместо уровней API - скрипт, который формирует окружение и запускает скрипт, который пишет и запускает скрипт, который, в свою очередь, дергает кучу других скриптов. Вот это - ок.
что характерно — очень часто это действительно вполне нормальное решение. но у вантузоидов от программ, которые на выходе дают другие программы, обостряется чувство собственной неполноценности.
> что характерно — очень часто это действительно вполне нормальное решение. но у
> вантузоидов от программ, которые на выходе дают другие программы, обостряется чувство
> собственной неполноценности.Ога. Особенно клево, когда оно записывает туда тексты, пропущенные через пятистрочные регекспы, а потом запускают с рутовыми правами. Не один SQL инъекциями богат...
что, бедняша, локалхост так навернул? оно завсегда если мозгов нет — то падает.
> что, бедняша, локалхост так навернул? оно завсегда если мозгов нет — то падает.Не, ну вообще-то у него есть пойнт. Я таким манером пару раз весьма изящно дурачил скрипты автоматического процессинга данных, как ты понимаешь, далеко не все в курсе про Бобби Тэйблса и его коллег по цеху :)
ну так специально можно и МПХ сломать, лишь бы цель такая стояла.
> ну так специально можно и МПХ сломать, лишь бы цель такая стояла.У скуля как раз неприятная особенность в том что он слишком много всего умеет by default. С другой стороны, нормальной k/v базе совершенно все-равно что получить на вход и что будет данными. Это избавляет от массы головняка.
Прелесть кв не в блобятине - на блобятину можно и скуль заточить (уже ж говорил - prepared statement, и никаких проблем). Прелесть в сравнительно шустром доступе к данным по ключу. С другой стороны, скуль и KV тихонько сливаются в экстазе - вон, NDB или TokuDB (TokuMX, если хотите NoSQL), и разница между ними становится в один парсер. Да и для InnoDB NoSQL access уже запилили. С inmemory тот же Inno/Toku не сравнить, конечно, но мы и не о inmemory говорим. А NDB неплохо так масштабируется, но он явно не эмбеддед :)Имхо будущее за гибридными движками хранилищ, к которым можно обратиться и так и сяк, в зависимости от потребности.
> Прелесть кв не в блобятине - на блобятину можно и скуль заточитьПрелесть - в том что k/v
1) Затачивать не надо - ему индиффирентно чего жрать с самого начала в большинстве реализаций.
2) Оверхеда на это ноль.
3) Сам по себе он быстрый.
4) Иньектить во многие реализации вообще совсем не получится.
5) Просто для понимания програмером. Если приходится вычитывать 1005000 записей - програмер быстро замечает неоптимальность. А в скуле он даже и не узнает о том что его select * from немеряная_таблица - это плохо. Потому что на его тестовом серванте с 10 записей и так катило. А вот когда это выкатят в продакшн - тут то и начнется конкретное ололо, при том не сразу, что особенно доставляет :)> (уже ж говорил - prepared statement, и никаких проблем). Прелесть в
> сравнительно шустром доступе к данным по ключу.Ну спасибо, Капитан. Это не просто "сравнительно шустрый" доступ. Это близко к наиболее быстрому с теоретической точки зрения для данной технологии стоража. Потому что это лобовая команда сторажу "дай вот это". Для b-дерева или хэш-таблицы это довольно быстрая и дешевая операция. Тот же токийский кабинет напрмер гарантирыет всего 2 запроса к диску на успех и 1 запрос к диску на неуспех.
И, кстати, к вопросу о размере и гектарах. В б-деревьях скорость относительно числа записей падает логарифмически, т.е. довольно медленно. В хэш-таблицах она вообще в среднем по больнице константа. По поводу чего сам по себе k/v или нечто подобное можно с чистой совестью юзать под очень масштабные применения. Майкрософтушка вон юзает какой-то относительно низкоуровневый ESE для AD о десятках миллионов объектов и Exchange с гигазами почты - и никакого вам скуля.
И если уж на то пошло - безбашенно накормить скуль запросом который где-то там внутри проелозит весь диск и все 100 000 000 записей - фигня вопрос. Достаточно безбашенено написать запрос и вытаскивание единственной записи будет занимать полчаса. В случае k/v сие делать неудобно, чисто технически. Програмер очень быстро заметит что его алгоритмика оставляет желать, в отличие от скуля, где это будет зарыто под слоем абстракций, которые хорошо понимает далеко не каждый кто использует SQL.
> С другой стороны, скуль и KV тихонько сливаются в экстазе - вон, NDB или TokuDB
> (TokuMX, если хотите NoSQL), и разница между ними становится в один парсер.А вот это в принципе логично, т.к. после парсера запрос по логике вещей можно скормить относительно простому и низкоуровневому сторажу, оперирующему куда более простыми вызовами. А дальше по мере надобности выбирать как лучше. Если видится вариант сразу представить все запросы в нативном понимании стоража, оптимально - значит так. А если такой вариант с наскока не придумался и/или ожидается усложнение абстракций - логично SQL заюзать.
> Да и для InnoDB NoSQL access уже запилили. С inmemory тот же Inno/Toku
> не сравнить, конечно, но мы и не о inmemory говорим.Как бы это сказать? Хороший key-value на быстром носителе типа SSD или тем более в RAM (cache hit или просто in-memory база) покажет именно эти самые свойства. Собственно in-memory и делают по каким-то таким технологиям, вся разница лишь в том что они обычно не имеют дело с диском напрямую и по этому поводу возможны некоторые послабления и упрощения иногда.
> А NDB неплохо так масштабируется, но он явно не эмбеддед :)
Ну если капитанить то у САБЖА кстати тоже есть SQLный фронтэнд, так что он и так и сяк умеет, правда тех кто юзал бы его через скуль я не видел, но при желании это можно :).
И если уж на то пошло, самому по себе key/value нет никаких причин не масштабироваться. Вон файловые системы до терабайтов масштабируются спокойно. Да и многие иные смогут. А чего б им? Лежащая в основе технология не чувствительна или мало чувствительна к размеру стоража сама по себе. Это програмер и его логика может облажать уже. Ну так оно и в SQL с нубами и select * тоже облажается. При том написать select * явно проще чем написать код явно читающий 100 000 записей, так что на SQL тормозные запросы как раз правило а не исключение :)
> Имхо будущее за гибридными движками хранилищ, к которым можно обратиться и так
> и сяк, в зависимости от потребности.Ну а вот это было бы логично - разделить на "парсер" и "движок". При этом можно было бы менять что парсер на какой-то кастомный, проблемо-ориентированный при нужде, так и движок, на тот который лучше подходит по свойствам. Ну так, в идеале.
> А в скуле он даже и не узнает
> о том что его select * from немеряная_таблица — это плохо.это не программер, это быдлокодер. быдлокодер что угодно испортит.
> это не программер, это быдлoкодер. быдлoкодер что угодно испортит.Нормальный спец по скулю, который реально понимает что реально будет сделано в ответ на тот или иной запрос - весьма редкий вид. Это крутые специалисты получающие вагон денег. На всех их заведомом не хватит и у всех не хватит денег на оплату таких гуру. Поэтому SQLное добрецо обречено создавать окружающим характерные грабли. Если рассмотреть весь процесс в целом.
ой, как будто на k/v не делают таких ужасов, когда смотришь и офигеваешь.
Да даже тот же MySQL Embedded можно встроить без особых проблем. Вопрос только в том, что весить оно будет бугага сколько...
> Да даже тот же MySQL Embedded можно встроитьНо лучше ты его себе куда-нибудь встрой. Ибо сдавать экзамен на пилотирование боинга при том что я всего-то на скутере хотел погонять - как-то больно недружественно ко мне получается.
А, ну так и скажите - порог вхождения не все осиляют. Это да, факт.
Другое дело, когда места посадить боинг / поставить хаммер нет - вот там скутер оправдан. Но в приличном ряде случаев монопенисуально.PS. Не об IT: на скутеры тоже права вводят. К чему бы это? Отсутствие порога вхождения провоцирует поведение на дорогах? :)
> А, ну так и скажите - порог вхождения не все осиляют. Это да, факт.Более того - по этому поводу большинство запросов на скуле - дикий ужас. Подавляющее большинство програмеров вообще не понимают во что их запрос будет трансформирован и в результате - пока у них тестовый сервер о 10 записях в базе - все работает. А вот потом становится очень интересно.
В kv базах они начинают замечать промахи в своих подходах очень быстро, т.к. двигло не прячет от прогремера свои проблемы в этом случае. А вот сиквель позволяет сильно нагрузить базу даже не узнав об этом вот так сразу. И да, заиметь это сакральное знание осиливает уже далеко не каждый первый кто запросы на сиквеле фигачит.
Может ли сиквель быть не слишком тормозным? Может. Если найти специалиста по ракетным наукам, который собаку на этом съел. Проблема только в том что такие спецы - редки как пингвины в пустыне Сахара и стоят совершенно диких денег. Поэтому их обычно не оказывается в нужном месте в нужное время. Результат достаточно плачевен.
> Другое дело, когда места посадить боинг / поставить хаммер нет - вот
> там скутер оправдан. Но в приличном ряде случаев монопенисуально.Дело даже не в том - скутер хорошо маневрирует и прост в управлении. А в указанном случае там еще и персональный ракетоплан до кучи встроен - при нужде такой скутер и в стратосферу без зазрения совести сгоняет, если ездок к этому готов.
> PS. Не об IT: на скутеры тоже права вводят. К чему бы
> это? Отсутствие порога вхождения провоцирует поведение на дорогах? :)Ну как бы да, глупое применение k/v тоже возможно. Но в современном мире намного больше глупых применений SQL, так что как видишь, скутерам в последнюю очередь достается - они далеко не основной источник проблем на дорогах :P.
> Ну как бы да, глупое применение k/v тоже возможно. Но в современном
> мире намного больше глупых применений SQL, так что как видишь, скутерам
> в последнюю очередь достается - они далеко не основной источник проблем
> на дорогах :P.Автомобилей тоже больше, чем скутеров...
> Автомобилей тоже больше, чем скутеров...А автомобиль по управлениию ближе к скутеру чем к боингу. Ы?
> BerkeleyDB, пол-программы переписывать? 0_о Вы похоже думаете,Я не "думаю", я видел эту либу лично и даже в ее кишках немного копался по технической необходимости. Это мощная либа с рядом фич, прямых аналогов которых у остальных нет.
Я охотно посмотрю как вы перепишете их апи курсоров например. А оно у "конкурентов" есть? И именно такое же? Даааа?
Ну, раз вы покопались в кишках, то расскажите нам, чем уникальны курсоры в BDB.На sql-платформах быстро переболели модным функциональным поветрием в виде курсоров. В BDB, как видите, оно осталось, за неимением другого механизма доступа к записям у которых ключи совпадают...
Если вам реализация api курсоров кажется сложной, почитайте про итераторы.
Кстати, lmdb шикарная вещь, по тестам делает berkeley.
> Кстати, lmdb шикарная вещь, по тестам делает berkeley.да и работает, вроде как, весьма стабильно. у меня, правда, не гигабайтные объёмы данных.
Лета не получилось. Вот почему анонимные школьники бороздят в просторах интернета.
> Лета не получилось. Вот почему анонимные школьники бороздят в просторах интернета.Как мне вас жаль. Sh*t happens.
ВНЕЗАПНО!
Оракле начали всё правильно делать
Но автор букв немного наркоман:>> Особенностью лицензии AGPLv3 является введение дополнительных ограничений
Но не ограничений же, требований обеспечения свободы
>> связывание с AGPLv3-библиотекой приведёт к распространению лицензии AGPLv3 на все использующие данную библиотеку пакеты
Так не надо статично линковать же
>> введя требования по открытию кода web-сервисов, использующих Berkeley DB, компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии.
А мне кажется, что оракле пытается стимулировать создателей перестать жопить код. И это очень правильное стремление. Особенно надо начать переставать жопить модифицированный код владельцам sas, построенным на переделанном под себя свободном софте. А то привыкли, что раз оно на сервере крутится, то можно взять и запроприетарить, раз юзерам только html отдаётся. Нехер.
>> владельцем имущественных прав на код
ШТО О_о?