форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от opennews (ok) on 07-Июл-13, 14:01
Компания 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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
Сообщение от Sabakwaka (ok) on 07-Июл-13, 14:01
Что за БРЕД?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	32. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от Sabakwaka (ok) on 07-Июл-13, 17:01
	Новость звучит, вообще-то, так: «Торговцы перепакованным BDB опасаются необходимости исполнять требованиями GPLv3»
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	40. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+9 +/–
	Сообщение от ананим on 07-Июл-13, 17:55
	Вообще-то она звучит так: >компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии. Что гораздо мягче вашего вброса. Зыж В данном случае для 3-ей стороны всё к лучшему. Пущай проприетарщики лбами стучатся кто из них опенсорснее.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	37. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 07-Июл-13, 17:52
	Беркелеевская база? От оракла? Под AGPLv3? Wtf? Оракл решил сказочно потроллить вообще всех и сразу чтоли? :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	44. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+4 +/–
	Сообщение от Andrey Mitrofanov on 07-Июл-13, 18:04
	> Беркелеевская база? От оракла? Под AGPLv3? Wtf? Оракл решил сказочно потроллить вообще > всех и сразу чтоли? :) Хотят в Зал Славы Интернетов, как Ричард!
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	53. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 19:37
	> Хотят в Зал Славы Интернетов, как Ричард! Тогда организаторы зала славы могут потроллить в ответ - засчитать как годное достижение, но к себе все-таки не вписать :)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

2. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+12 +/–
Сообщение от Аноним (??) on 07-Июл-13, 14:01
Да, неприятная ситуация. Могут пострадать многие уважаемые проприетарные вендоры.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+9 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 14:05
	> уважаемые > проприетарные /0
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	11. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+12 +/–
	Сообщение от BlackRaven86 (ok) on 07-Июл-13, 14:52
	Мне кажется, тут стоит вспомнить о sarcasm.jpg
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Full inu on 07-Июл-13, 14:06
	> Да, неприятная ситуация. Могут пострадать многие уважаемые проприетарные вендоры. ох тыж ёшкин кот
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

Часть нити удалена модератором

	87. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:40
	> Да - это делается единолично. Называется "накруткой голосов". Вообще-то на опеннете приняты некоторые меры для того чтобы накручивать было не то чтобы совсем невозможно, но достаточно паливно + неудобно. Думашь, ты кому-то настолько нужен? Даже мсовских ботов серьезно накручивать ломает в силу озвученных факторов. Поэтому таки да, жмет натурально 30 разных перцев. Ну может 20-25, с учетом накруток. Просто сообщения которые вверху треда, в свежей новости - читают все. Им то и достается наибольшее зрительское внимание. А 125-й комментарий сверху - находят только самые упорные. Остальных читать флуд типа твоего спама утомляет максимум на втором десятке коментов и они это не читают. Ну и оценки там никто не жмет, т.к. не читают :). В лучшем случае - участники затянувшегося спора остаются и плюсы-минусы в небольшой количетве - от них.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от Zenitur (ok) on 07-Июл-13, 22:12
	>> Путен не ошибается, Столлман святой, Шаттлворт всегда прав, а GPL v.3 не обладает минусами. > Мда. Zenitur такой zenitur. Неожиданно. Ты осуждаешь меня за мою насмешку. Ты РЕАЛЬНО соглашаешься со всеми этими высказываниями? Взрослей: сколько людей, столько и мнений, или проще говоря: не все, кто не согласны с твоим мнением, враги и их надо НИНАВИДЕТЬ.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	133. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 13:28
	Нет. Тебя осуждают за то, что ТЫ соглашаешься с этими высказываниями.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

4. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+8 +/–
Сообщение от ip1981 (ok) on 07-Июл-13, 14:06
Oracle, конечно, какашка, но AGPL это правильное направление. P. S. Читайте рассылку Дебиана и приведённые там ссылки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 07-Июл-13, 14:15
	> Oracle, конечно, кaкaшка, но AGPL это правильное направление. Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам. Такой "оpакл". В полный рост. > P. S. Читайте рассылку Дебиана и приведённые там ссылки. Предложил местной публике прочитать анализ Бредли Кюна и _понять его? Толстячок.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	18. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 07-Июл-13, 15:20
	> Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам. Такой "оpакл". > В полный рост. Кругом враги©
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	20. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Andrey Mitrofanov on 07-Июл-13, 15:24
	>>Такой "оpакл". В полный рост. > Кругом враги© Молодящаяся копирастическая - в кольце вагов. Да.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от 1 (??) on 07-Июл-13, 15:29
	ахаха митрофанов опять разоблачает =) не устал еще покровы срывать?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	23. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+5 +/–
	Сообщение от Andrey Mitrofanov on 07-Июл-13, 15:35
	> ахаха митрофанов опять разоблачает =) не устал еще покровы срывать? Сам-то, решил прикрыться, ник фейкнул. Терапия помогает - задумался, так держать.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	45. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от 1 (??) on 07-Июл-13, 18:05
	расслабься, здесь нет тайны - у меня лишь нет желания регаться на лороподобных ресурсах :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	88. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:41
	А регаться никто и не заставляет. Просто если уж решил стать прославленным дятлом - не бросай с полдороги, не огорчай публику.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	116. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 09:53
	> расслабься, здесь нет тайны - у меня лишь нет желания регаться на > лороподобных ресурсах :) Кстати, FAIL. Я, :-P например, не зарегистрирован на этом ресурсе. И да, имя настоящее. И да, был идiот, который подделывал. И ты не стесняйся. Не, не моим именем подписываться. Понял-понял или повторить?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	29. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Sabakwaka (ok) on 07-Июл-13, 16:55
	>> Фигу показал ТОРГУЕШЬ agpl софтом или получаешь прибыль от веб-проекта, использующего agpl софт? — выкладывай исходники. Где проблема-то? Просто «теперь и в Интернете». При этом альтернатив BDB — хватает. Если проблема ещё и в том, что нет сил лень сменить движок, то я уже не знаю, что сказать.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	39. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+3 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 17:54
	> Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам. А заодно еще и беркелей с их лицензией потроллили :)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	90. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:44
	> А заодно еще и беркелей с их лицензией потроллили :) Как правило, то, что содержит в названии Berkeley, весьма слабо относится к Berkeley. Поэтому Berkeley DB распространяется отнюдь не под BSDL.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	97. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:23
	Да не, все проще: корпорасы показали лишний раз что вытереть ноги о тех кто метит в роль коврика - обычная практика :).
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	164. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:14
	Это вы к тому как относился автор MySQL к коврикам из GPL ?
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	182. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:37
	Фиговые из GPL коврики - жесткие и кусачие. Поэтому тут что-то сделать может только автор, который имеет полное право в нужных местах убрать GPL и положить более мяг^W"свободный" коврик.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	184. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:40
	> Поэтому тут что-то сделать может только автор Точнее, правообладатель. Например, если ты участвуешь в проекте под эгидой Canonical, ты автоматически утрачиваешь все права на лицензирование своего кода - этим теперь заведует лично Марк. Захочет - выпустит под GPL, а кому надо - сделает полный и эксклюзивный пермиссив.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	186. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:48
	> Это вы к тому как относился автор MySQL к коврикам из GPL ? А там ковриком сам оракл выступил походу :)
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	122. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от SubGun (ok) on 08-Июл-13, 10:32
	> Oracle, конечно, какашка, но AGPL это правильное направление. Что-то дорабатывать или улучшать? Зачем? Лучше сменить лицензию, чтобы создать видимость работы.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	134. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 13:30
	> Что-то дорабатывать или улучшать? Когда человек с ником SubGun начинает втирать про доработку и улучшение - это уже смешно.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	136. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от ip1981 (ok) on 08-Июл-13, 13:51
	>> Oracle, конечно, какашка, но AGPL это правильное направление. > Что-то дорабатывать или улучшать? Зачем? Лучше сменить лицензию, чтобы создать видимость > работы. Я про AGPL вообще, причём для программ, а не библиотек, и вообще аккуратно.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

6. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
Сообщение от klalafuda on 07-Июл-13, 14:12
Вот так в один прекрасный день проснешься, наберешь на автомате apt-get update && apt-get upgrade и - привет, статья. PS: Впрочем, слипкаты отродясь не вызывали к себе особого доверия. Пользователи BDB в их 'свободной' реинкарнации ССЗБ.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+3 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 15:13
	Конечный пользователь (не распространяющий ПО в бинарном виде) никак не может нарушить xGPL, поскольку та его никоим образом  не ограничивает. Ограничения касаются только тех, кто распространяет софт, поэтому засудить можно только распространителей бинарных сборок: майнтейнеров бинарных дистрибутивов и вендоров проприетарного софта.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	38. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–4 +/–
	Сообщение от бедный буратино (ok) on 07-Июл-13, 17:53
	AGPL касается и веб-сайтов (причём всех его компонентов), и любых других сервисов. Это может создавать проблему. Кстати, будет ОЧЕНЬ смешно, если на такую же лицензию переведут mysql. Это будет пыхерокапец, ВСЕХ пыхеров обяжут открыть ВЕСЬ код, и от обилия этого добра планета задохнётся и рухнет под тяжестью.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

Часть нити удалена модератором

	67. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+3 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 22:04
	> ты всё равно не понял, что я сказал > и совсем не потому, что я сказал что-то сложное для понимания... ... а потому, что ты просто не смог сформулировать свою мысль.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	48. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от klalafuda on 07-Июл-13, 18:19
	> AGPL касается и веб-сайтов (причём всех его компонентов), и любых других сервисов. Это может создавать проблему. Я так полагаю, что это сугубо теоретически. По крайней мере мне пока что не попадался ни один веб-сайт, который бы в трезвом уме и здравой памяти использовал BDB & K. Ибо нахрена она там, пардон мой французский?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	125. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–5 +/–
	Сообщение от бедный буратино (ok) on 08-Июл-13, 10:48
	Это вменяемое средство для сохранения данных. Вот когда для построения страницы используется 11 sql запросов только для хранения данных - это не совсем понятно. А bdb - это очень мощная система, которая позволяет обращаться к данным, как к данным, а не с помощью языка запросов. В том же python поддержка bdb есть "из коробки", почему бы не воспользоваться, если нужны просто данные по ключу, а тот же mongodb явно избыточен (или его нет "из коробки") Я бы использовал его для данных, если бы он был чуть попроще. А так, все эти режимы б-деревьев и прочее, когда нужно выбирать оптимальный режим, не имея на это достаточно данных - мне-то достаточно и совсем простых средств. А кому-то - недостаточно.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	187. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:03
	> же python поддержка bdb есть "из коробки", почему бы не воспользоваться, Потому что ты уже достал со своим бидоном.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	202. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:29
	это невменяемый древний капец, который нормальные люди давно заменили на qmdb/lmdb/tokyo cabinet/kyoto cabinet/и-так-далее. вообще, key/value баз — как грязи.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	264. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:00
	> это невменяемый древний капец, который нормальные люди давно заменили на qmdb/lmdb/tokyo > cabinet/kyoto cabinet/и-так-далее. вообще, key/value баз — как грязи. Да не, на самом деле нормальная либа вполне. Правда навороченная и не особо шустрая.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	284. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 13:34
	ок, насчёт «невменяемый» я погорячился, конечно. либа как либа. но далеко не «единственная в своём роде».
	Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

	318. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 19:39
	> ок, насчёт «невменяемый» я погорячился, конечно. либа как либа. но далеко не > «единственная в своём роде». Просто в апи есть ряд фич, прямые аналоги у "конкурентов" которым могут отсутствовать. И насколько малой кровью удастся переписать - зависит от того насколько там эти фичи апи либы использовались. Но то что либ подобного класса в природе море - факт. По поводу чего столь резкий маневр оракла вызывает ряд вопросов.
	Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

	66. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 22:02
	> Кстати, будет ОЧЕНЬ смешно, если на такую же лицензию переведут mysql. Это > будет пыхерокапец, Не будет. Старые версии нельзя перелицензировать задним числом, а вот форкнуть проект под старой лицензией - запросто (см. MariaDB). > ВСЕХ пыхеров обяжут открыть ВЕСЬ код, и от обилия этого добра планета задохнётся и рухнет под тяжестью. Ты забыл еще пистонщиков и рубистов - они ничем не лучше.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	84. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от AlexAT (ok) on 07-Июл-13, 23:05
	Чу'дную ересь несёшь. Правда-правда. Даже если оракль переведет MySQL на AGPL3/GPL3 - всегда останется MariaDB или любой другой форк от того момента, когда оно было под GPL2. Это раз. Два - тут уже не только PHP, тут уже всё придётся открывать. Включая многие коммерческие сервисы, если уж на то пошло. Фейсбуки, гуглы, вконтакты, твиттеры и много чего еще. Это два. 70-80% сайтов с динамикой. Банковские системы (угу, MySQL есть и там). И так далее. Поэтому даже если оракл решится на такой шаг - мне кажется, это им только боком выйдет - все сразу же соскочат на форки, и поддержку MySQL, за которую берутся деньги, можно будет сворачивать. Вряд ли они себе настолько враги.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	92. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:47
	> Чу'дную ересь несёшь. Правда-правда. А теперь посмотри на имя автора того комментария. Еще вопросы есть?
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	123. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от бедный буратино (ok) on 08-Июл-13, 10:44
	> Поэтому даже если оракл решится на такой шаг - мне кажется, это им только боком выйдет - все сразу же соскочат на форки Как будто обилие проблем винды заставило всех соскочить на свободные системы? Платят (прямо или косвенно), мучаются, но продолжают пытаться испытать удовольствие. Стереотип тем и силён, что не обязан быть правдой. Но я не думаю, что реально это будет, потому что тогда придётся претензии реально к каждому сайту выдвигать, чтобы доказывал, что он не верблюд. Я только говорю, что это бы очень смешно выглядело со стороны. Хотя, постойте. Мне вспоминается что-то подобное: "Microsoft против андроидов", "Microsoft против linux-навигаторов", "Microsoft против linux-электроники". И как-то это выглядело совсем не смешно. Кстати, oracle уже один раз изменила условия "заочно", в результате чего уже существующую java пришлось удалять из всех репозиториев. Там, глядишь, и в maria-системах обнаружатся какие-то "патенты", которые мы "не покажем", но которые непременно "нарушают". Это же капитализм, который защищает капиталы от человека. Человек человеку волк.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	142. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:23
	> Это же капитализм, который защищает капиталы от человека. Человек человеку волк. А опенсорс вот как-то работает, всем волкам назло. И как-то так более разумные существа начинают заруливать волчьи стаи, распихивая представителей по зоопаркам.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	165. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:16
	> Чу'дную ересь несёшь. Правда-правда. > Даже если оракль переведет MySQL на AGPL3/GPL3 - всегда останется MariaDB или > любой другой форк от того момента, когда оно было под GPL2. > Это раз. а чем вам последователям столмана не нравится GPL v3 ? Вы же призываете сразу подписываться под всеми будущими лицензиями ставя GNU GPL vX or later...
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	188. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:05
	> а чем вам последователям столмана не нравится GPL v3 ? Как раз наиболее радикальные последователи могут радоваться - такое воротило как оракл продавливает своей массой такую лицензию. Прямо странно даже.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	200. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:58
	> Как раз наиболее радикальные последователи могут радоваться - такое воротило как оракл > продавливает своей массой такую лицензию. Прямо странно даже. И каноникал тоже свой убунтофон под GPLv3. Чудеса в решете! А секрет просто - они всего лишь намекают вендорам, что неплохо было бы "договориться по-хорошему", с уплатой определенных сумм.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	259. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 11:47
	>> Как раз наиболее радикальные последователи могут радоваться - такое воротило как оракл >> продавливает своей массой такую лицензию. Прямо странно даже. > И каноникал тоже свой убунтофон под GPLv3. Чудеса в решете! > А секрет просто - они всего лишь намекают вендорам, что неплохо было > бы "договориться по-хорошему", с уплатой определенных сумм. О? Как мило! Вы ж бессеребренники, с бесплатным и безлимитным свободным временем! Какие еде суммы? Патчи от линя в уплату используйте, ёба!
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	267. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:04
	> Какие еде суммы? Патчи от линя в уплату используйте Лично меня вполне устраивают патчи которые чинят имеющиеся на моих конфигурациях проблемы :). Иногда это вполне себе кaтит за оплату. А своими кoмплексами стyдня, вкaлывающего на проприетарей за дoширак можно и поменьше светить, вообще-то.
	Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

	255. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Пингвино (ok) on 09-Июл-13, 10:06
	> Вряд ли они себе настолько враги. Cо здравым смыслом они не особо дружат, так что вполне ожидаемо.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

8. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от paulus (ok) on 07-Июл-13, 14:24
Новые козни Оракли:) "компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
Сообщение от MrClon on 07-Июл-13, 14:40
>Таким образом, введя требования по открытию кода web-сервисов, использующих Berkeley DB, компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии. Очень некрасиво получается. По сути весьма годная свободная лицензия используется Ораклом для вытрясания денег.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Magister on 07-Июл-13, 14:51
	Та как раз наоборот, всё красиво. Зарабатываете деньги - извольте поделиться, раз уж используете наш софт. Не зарабатываете - используйте бесплатно. Всё честно.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Magister on 07-Июл-13, 14:56
	Только вот свободный софт, который, скажем, GPLv2 - уже несовместим получается... вот это плохо. Лучше бы они v2 выбрали.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	30. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от Sabakwaka (ok) on 07-Июл-13, 16:57
	> Только вот свободный софт, который, скажем, GPLv2 - уже несовместим получается... вот > это плохо. > Лучше бы они v2 выбрали. несовместим получается мудофил, которого не устраивают условия AGPL
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	89. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:42
	> несовместим получается мудофил, которого не устраивают условия AGPL Авторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	167. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–4 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:17
	>> несовместим получается мудофил, которого не устраивают условия AGPL > Авторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы. Ну так товарищь Столман сознательно их сделал не совместимыми.. Так в чем проблема ?:)
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	176. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:32
	> Ну так товарищь Столман сознательно их сделал не совместимыми.. Ага, а еще он ест детей.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	189. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:06
	> Ну так товарищь Столман сознательно их сделал не совместимыми.. Так в чем проблема ?:) Ну да, а ПДД сделали "несовместимым" с спортивными автомобилями, запретив гонять на 200 км/ч в городской черте. Вот ведь гады кто это ПДД придумал! Никакого покоя стритрэйсерам нет - постоянно копы мешают убиваться и других сшибать!
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	225. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 22:52
	некоректное сравнение. Скорее уж так - вы едите едите на машине с круглыми колесами - и вдруг бац.. требование только на квадратных - и никакие аргументы что так не удобно - не влияют - подписался ехать по этой дороге - одевай квадратные или вали с нашей дороги.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	227. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 01:33
	Требование открытости кода, который ты _распространяешь_ (а не используешь для нужд своей фирмы) == квадратные колеса? Походу, у тебя в голове баг. И, возможно, даже не один.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	261. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 09-Июл-13, 11:53
	Но уж никак не требование ПДД не гонять :-) Ближе к квадратным колесам.. Хотя может ближе к тому что - ты взял прокатиться велосипед - а у тебя начали выворачивать карманы под предлогом что ты съездил в банкомат и снял деньги, а значит попользовался велосипедом и получил прибыль?
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	268. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:06
	> подписался ехать по этой дороге - одевай квадратные или вали с нашей дороги. Не, не так. Если тебе не нравится ПДД - вали, создавай другое государство, становись президентом и принимай там другое ПДД. Если принималка не сломается.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	203. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:31
	>> несовместим получается мудофил, которого не устраивают условия AGPL > Авторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы. взяли — и заменили v2 на v3. что? в проекте написано v2 only? идиоты должны страдать.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	49. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 07-Июл-13, 18:25
	> Та как раз наоборот, всё красиво. > Зарабатываете деньги - извольте поделиться, раз уж используете наш софт. > Не зарабатываете - используйте бесплатно. > Всё честно. Всё бы правильно, да ведь и на свободном движке можно зарабатывать деньги, совершенно спокойно. В тех же web-сервисах, зачастую, решает контент и раскрученность, а также пользовательская база, чему открытый исходный код не только не мешает, но может и помочь.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	94. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:54
	> Всё бы правильно, да ведь и на свободном движке можно зарабатывать деньги, > совершенно спокойно. В тех же web-сервисах, зачастую, решает контент и раскрученность, > а также пользовательская база, чему открытый исходный код не только не > мешает, но может и помочь. Один момент - безопасность. Воспользоваться уязвимостью веб-движка гораздо проще, чем уязвимостью в прикладной программе. Поэтому в ход должны пускаться все возможные методы защиты, вплоть до security by obscurity.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	100. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:38
	> security by obscurity. Т.е. впаривания лоху г@вна завернутого в красивый фантик. Называя вещи своими именами.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	131. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 13:11
	> Т.е. впаривания лоху г@вна завернутого в красивый фантик. Называя вещи своими именами. Опенсорсность никак не мешает этому процессу, как показал нам коcмонавт.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	148. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:36
	> Опенсорсность никак не мешает этому процессу, как показал нам кocмoнавт. А у кoсмoнавта, btw, вполне нормальная система. Не хуже остальных. С точки зрения пользователя - там симпатичные темы, шрифты и прочая из коробки, более-менее нормальная подборка софта для повседневных задач и прочая. А в остальном - тот же дeбиан, вид в профиль. Ну, цикл релизов еще повмeняемее для десктопа чем у оригинала. В остальном - попробуйте найти 10 различий. ИМХО как раз удачно вышло: дебиан хорош как база, а каноникал хороши как те кто отпoлировал видимые юзерям шерoховатости в этой базе.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	161. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:07
	Что и требовалось доказать.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	190. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:09
	> Что и требовалось доказать. От дополнительной полировки дебиан в г@вно отнюдь не превратился. Как ни странно, в красивую обертку можно еще и конфеты класть. Вот Дебиан - конфеты в развес, без фантиков вообще. А убунта - "retail" версия, уже с фантиками и подороже.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	194. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:49
	Был довольно пaршивый дистр (кстати из недавнего: замечательная идея - при минорном обновлении софтины грохать базу, которую эта софтина использует), который при помощи арч-стайл пиoнерии был превращен в тормозное и глюкaвое минное поле, которое дохнет от малейшего обновления. Но технический аспект, как известно, ничто, а рулить только пиар. И хомячки бодро ринулись на мины. ИЧСХ, даже ежедневно подрываясь на них, продолжают их нахваливать.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	271. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:18
	> Был довольно пaршивый дистр Дебиан вполне обычен и даже зауряден как дистр, но есть и несколько козырей. 1) У них хороший пакетный менеджер. Лучше чем у многих других. 2) У них куча пакетов в репозиториях на все вкусы. 3) Это замечательная "база" для построения на его основе деривативов. Потому как щепетильны к лицензиям, патентам и прочему. > (кстати из недавнего: замечательная идея - при минорном > обновлении софтины грохать базу, которую эта софтина использует), Кстати, идеального софта в этом мире не бывает - можно до...ться к любой программе сложнее hello world. А к дистру с 20 000+ пакетов можно априори до...ться по туевой хуче предъяв. Кстати, а это в stable было? Если нет - ну вы сами себе злобный баклан, потому что названия "testing" и "unstable" прозрачно намекают, если что. В stable подобные приколы обычно себе никто не позволяет. В более камикадзевых ветках - зависит от. > который при помощи арч-стайл пиoнерии был превращен в тормозное и глюкaвое минное поле, Не вижу ничкакой арч-стайл пиoнерии. А глючит там только питонятина от каноникала. Которую можно просто выпилить за 5 минут манагером пакетов, т.к. нафиг все эти ubuntu one и софтвар центры, скажем честно :) > которое дохнет от малейшего обновления. И, конечно же, нас завалит пруфами? :) > Но технический аспект, как известно, ничто, а рулить только пиар. Технический аспект у граждан вполне нормальный. Не хуже чем у остальных. А вы свой любимый дистр назовите - мы ему тоже по техническим моментам косточки пересчитаем.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	204. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:33
	> Поэтому в ход должны пускаться все возможные методы защиты, вплоть до > security by obscurity. «security by obscurity» — это метод не защиты от уязвимостей, а защиты уязвимостей от клиентов.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	215. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 21:32
	> «security by obscurity» — это метод не защиты от уязвимостей, а защиты > уязвимостей от клиентов. Не только от клиентов. Хотя от того же тупого пентестинга сканером, конечно, не защитит никак.
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	220. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 21:58
	в основном — от клиентов и security reviewers. о чём клиент не знает — того нет. и заказать аудит сторонним экспертам сильно сложнее, потому что надо или реверсера дополнительно брать, или за код бодаться.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	13. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–8 +/–
	Сообщение от klalafuda on 07-Июл-13, 15:04
	> Очень некрасиво получается. По сути весьма годная свободная лицензия используется Ораклом для вытрясания денег. Свободные лицензии - это MIT, BSD, Apache, Boost. *GPL же изначально вводились в оборот сугубо для отжатия бабла. И, надо признаться, весьма успешно действуют на этом поприще.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	17. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 15:19
	А ваши "свободные" - для отжатия халявной рабсилы. С чем тоже успешно справляются.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	260. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 11:50
	> А ваши "свободные" - для отжатия халявной рабсилы. С чем тоже успешно > справляются. Чума на оба ваших дома.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+4 +/–
	Сообщение от Andrey Mitrofanov on 07-Июл-13, 15:22
	>> По сути весьма годная свободная лицензия используется Ораклом > Свободные лицензии - это MIT, BSD, Apache, Boost. *GPL же изначально вводились > в оборот сугубо для отжатия бабла. И, надо признаться, весьма успешно > действуют на этом поприще. То ли дело NVidia, VIA, ARM, Juniper, ...Apple! "Great Artists Steal." *Такие* мо-лод-цы!! </opa izenмэн style> Такие мо-лод-цы ещё и деньги _раздают в отличие от суппостата Столмана! Да! И работают на Благо _за_еду_, гусары с дамм денег не берут.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	21. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 15:27
	> </opa izenмэн style> Открывающий тег потерял. Валидатор не одобряет.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	101. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:39
	> Открывающий тег потерял. Валидатор не одобряет. Настоящий парсер ставит нужные теги по контексту сам. А вот тyпоботы - палятся, их валидатор не может отслеживать контекст :)
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	118. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 09:58
	>А вот тyпоботы - > палятся, их валидатор не может отслеживать контекст :) :) Тест Тьюринга: NO CARRIER Неожиданно положительный результат.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	31. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от Sabakwaka (ok) on 07-Июл-13, 16:57
	>> Очень некрасиво получается. По сути весьма годная свободная лицензия используется Ораклом для вытрясания денег. > Свободные лицензии - это MIT, BSD, Apache, Boost. *GPL же изначально вводились > в оборот сугубо для отжатия бабла. И, надо признаться, весьма успешно > действуют на этом поприще. Оть иманна.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	36. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от vitalif on 07-Июл-13, 17:36
	GPL как раз вводилась в оборот, чтобы всякие умники-коммерсанты не могли отжимать бабло с нормальных людей. И чтобы софт был действительно свободным. А не как в BSD-лицензиях, когда хромиум свободный, а хром всё равно закрытый и с гуглозондами.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	85. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Гость on 07-Июл-13, 23:20
	С хромом плохой пример, например mysql прекрасно бывают и свободная и коммерческая.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	86. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 23:37
	Ну дык правообладатель может выдавать кому угодно какие угодно лицензии.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	109. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от vitalif on 08-Июл-13, 02:09
	Хм... Ну да. Но не факт, что гугл бы был эксклюзивным правообладателем вебкита...
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	107. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:49
	> Свободные лицензии - это MIT, BSD, Apache, Boost. Список проприетарных подстилок не полный. MS PL где? Как посмотришь на продукцию эпплов и жуниперов - оттуда свобода так и прет во все щели :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	140. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 14:47
	ты перепутал - эти лицензии признаны свободными и открытыми.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	145. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:28
	> ты перепутал - эти лицензии признаны свободными и открытыми. Открыты они прежде всего для проприетарщиков.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	149. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:40
	> ты перепутал - эти лицензии признаны свободными и открытыми. Я не знаю для кого оно там свбодное и открытое, но если я куплю железку от жунипера, эппла или сони - я что-то совсем не наблюдаю там обещанных свобод. Походу свобода есть только у этой троицы, а у остальных - только дырка от этого бублика.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	163. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:13
	Да, эти лицензии свободные. Но не для тебя.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	169. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–5 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:20
	>> ты перепутал - эти лицензии признаны свободными и открытыми. > Я не знаю для кого оно там свбодное и открытое, но если > я куплю железку от жунипера, эппла или сони - я что-то > совсем не наблюдаю там обещанных свобод. Обещаных кем? цитату плиз? Я вот вижу как RedHat обещавший всего и много - потихоньку закрывает бизнес.. Вот уже и FAQ закрытым стал.. только по подписке..
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	178. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:35
	> Я вот вижу как RedHat обещавший всего и много - потихоньку закрывает > бизнес.. Вот уже и FAQ закрытым стал.. только по подписке.. Да и в LKML уже патчи не присылают...
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	192. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:14
	> Да и в LKML уже патчи не присылают... Ну да, а какой-нибудь Дэйв Эйрли из редхата  в курсах о том какой он там жадный жлоб? А в графической подсистеме его копирайтов - хоть отбавляй. Да, в исходниках ядра. На моем диске. Это редхат, значит, такой жадный и ничего не присылает? :)
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	195. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:51
	> Ну да, а какой-нибудь Дэйв Эйрли из редхата  в курсах о > том какой он там жадный жлоб? А в графической подсистеме его > копирайтов - хоть отбавляй. Да, в исходниках ядра. На моем диске. > Это редхат, значит, такой жадный и ничего не присылает? :) Ну так Linux - проприетарное пoделие, это тебе любой линуксмастрип расскажет.
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	191. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:11
	> Обещаных кем? цитату плиз? Да вон вы утверждаете же "ты перепутал - эти лицензии признаны свободными и открытыми". Кем-то может и признаны, а если я куплю что-то от сони, жунипера и эппла - мне с этого только дырка от бублика достанется а не "свобода". Нафига бы мне такой расклад? > Я вот вижу как RedHat обещавший всего и много - потихоньку закрывает > бизнес.. Вот уже и FAQ закрытым стал.. только по подписке.. Тем не менее, у меня в ядре довольно много кода от этого самого редхата вкалывает на мое благо. А все остальное меня честно говоря интересует довольно слабо.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	216. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 21:44
	Хм.. код который взял кто-то и под себя додел что куда-то пропал? вы его взять не можете? Или вы хотите на халявую чужую работу взять?
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	273. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:25
	> Хм.. код который взял кто-то и под себя додел что куда-то пропал? > вы его взять не можете? Внезапно, да. У сони на PS4 есть игры. А на фрибсдах - дырка от бублика. И уж конечно никаких патчей от сони. И вообще конкретная з@дница с драйверами GPU. > Или вы хотите на халявую чужую работу взять? Ну если мою работу можно брать нахаляву, тогда и я хочу так же мочь. А что, я самая главная дойная корова вам тут чтоли? Пусть корпорасы бесплатно катаются на вашей хребтине, если вам это по кайфу. А как по мне - или уж "равный-равный", или уж "GTFO". Участвовать в процессе на условиях второго сорта и бесплатной рабсилы мне нет никакого резона.
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	170. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 16:22
	> ты перепутал - эти лицензии признаны свободными и открытыми. Они также являются свободными для _закрытия_. В отличие от. Это коренно-и-отлично, да.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	43. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 18:02
	> для вытрясания денег. Или отдачи в проект. Второй вариант не так уж и плох.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	47. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от klalafuda on 07-Июл-13, 18:15
	> Или отдачи в проект. Второй вариант не так уж и плох. Вы таки действительно верите в то, что Оракел спит и мечтает, чтобы ему кто-то что-то куда-то отдавал?!
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	102. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:41
	> Вы таки действительно верите в то, что Оракел спит и мечтает, чтобы > ему кто-то что-то куда-то отдавал?! Гм, вообще, ситуация когда корпорас отпинывается ногами от желающих поработать на них совершенно бесплатно - видится мне довольно странной и дикой. Это как-то совсем не по капиталистически прямо.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	127. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от klalafuda on 08-Июл-13, 11:07
	> Гм, вообще, ситуация когда корпорас отпинывается ногами от желающих поработать на них совершенно бесплатно - видится мне довольно странной и дикой. Это как-то совсем не по капиталистически прямо. Народное правило "Скупой платит дважды" ещё никто не отменял. Оракл - это корпоратив. Со своим workflow разработки, требованиями к коду и тд и тп. Попытки встроить в эту структуру механизм принятия патчей от сторонних разработчиков с большей вероятностью приведут к фейлу. Геморрою вагон с тележкой а сухого остатка - пшик. При таком раскладе естественное решение вопроса приема сторонних патчей - тупо посылать их лесом и не заморачиваться. Благо, в случае необходимости своих кодеров у Оракла в достатке. GPL в обсуждаемом случае - это отнюдь не инструмент привлечения сторонних разработчиков в проект ибо они там нахрен никому даром не сдались. Это shareware чистой воды. Хотите попробовать? Берите, пробуйте как вам угодно - не вопрос. Хотите реально использовать? Платите и используйте. Решили остаться на GPL версии? Бога ради. Вы не наш клиент. Следующий.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	150. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:42
	> Народное правило "Скупой платит дважды" ещё никто не отменял. Вот проприетарщики и ощущают это на своей попе во весь рост, все сильнее и сильнее :) > Оракл - это корпоратив. Со своим workflow разработки, требованиями к коду и тд и тп. > Попытки встроить в эту структуру механизм принятия патчей от сторонних разработчиков с > большей вероятностью приведут к фейлу У бездарей - приведут. А вон в линевом кернеле например прокатило. Выбрали некие условия которые более-менее всех устроили, ну и работают по ним. Достаточно предсказуемо, кстати. Кровавым ынтырпрайзам и то понравилось даже. Хотя некоторые предпочли вратаря на воротах содержать, типа редхата или кого там еще.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

14. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от Омский линуксоид (ok) on 07-Июл-13, 15:10
Вообще, это ужасно, что BERKELEY DB не под родной лицензией BSD (BERKELEY Software Distribution)... Они теряют корни.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 07-Июл-13, 20:48
	Вступят в евросоюз
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Июл-13, 15:15
> Berkeley DB входит в числе базовых библиотек, от которых зависят многие пакеты. несмотря на это, bdb мало где используется по факту и мало где является ключевым  незаменимым компонентом. Нефиг собирать пакеты со всеми ненужными зависимостями и тем самым делать их базовыми.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от Stax (ok) on 07-Июл-13, 15:40
	Эээ "редко, но метко". rpm использует bdb, а это ключевой компонент многих дистрибутивов. Также Berkeley DB нужен для pam (не уверен, может ли pam использовать что-то еще, но в разных дистрибутивах, где сейчас проверил, везде использует bdb). Без pam нынче нормально можно жить разве что в ембеддовке. Ну и до кучи, iproute2 требует bdb. Тут вообще без комментариев.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	25. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 07-Июл-13, 15:47
	>нужен для pam >iproute2 требует bdb. Тут вообще без комментариев. 15.02.2006 12:42  Компания Oracle купила Sleepycat Software Ай-яй-яй, за ними пришёл пушистый маленький оракел!??
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	28. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+4 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Июл-13, 15:56
	> Эээ "редко, но метко". rpm использует bdb, а это ключевой компонент многих дистрибутивов. с rpm'ом это проблема, но тем не менее не сложно переписать на других аналогах. Да и не дебиановская пичаль. > Также Berkeley DB нужен для pam (не уверен, может ли pam использовать что-то еще, но в разных дистрибутивах, где сейчас проверил, везде использует bdb) в PAM bdb используется для эзотерических фич и в большинстве практических кейсах никогда не юзается. Собирается оно опционально и есть в разных дистрибутивах только потому, что какой-то удак решил собирать PAM  с данной опцией. > Ну и до кучи, iproute2 требует bdb. аналогично, нафиг не нужен и прекрасно в % 99.9 кейсах работает без него. Собрали с ним ~ 'шоб было' я же об этом именно и пишу выше, что почти везде в бинарных дистрибутивах приклеили bdb от нефиг делать. И само использование bdb является оверкилом в 9 из 10 пакетах, какого-нибудь gdbm вполне хватает для требуемой функциональности.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	93. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:49
	> Также Berkeley DB нужен для pam (не уверен, может ли pam использовать > что-то еще, но в разных дистрибутивах, где сейчас проверил, везде использует > bdb). Без pam нынче нормально можно жить разве что в ембеддовке. Хм. Слаководы вполне себе живут без PAMа, потому что им гуру запретил.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	103. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+6 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:42
	> Хм. Слаководы вполне себе живут без PAMа, потому что им гуру запретил. Да им не привыкать, там вся система - "...и удобства во дворе".
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	146. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:31
	> "...и удобства во дворе" Удобства не нужны же.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	151. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+3 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:43
	> Удобства не нужны же. Только зимой ж@па мерзнет, а так ничего.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	196. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:53
	> Только зимой ж@па мерзнет, а так ничего. Потому что ты идиoт. А я умный, у меня ничего не мерзнет. © arisu
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	275. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:28
	> Потому что ты идиoт. А я умный, у меня ничего не мерзнет. © arisu Ага, можно конечно ставить костыли своему "скворечнику" и даже буржуйку для отопления поставить. Но нормальные люди ставят в доме унитаз а не занимаются извращениями с окультуриванием "скворечника" и воркэраундом проблем.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	291. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 13:52
	угу. вот я и не занимаюсь борьбой с системой вместо нормального её использования.
	Ответить | Правка | ^ к родителю #275 | Наверх | Cообщить модератору

	311. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:55
	> угу. вот я и не занимаюсь борьбой с системой вместо нормального её использования. Вполне имеющий право на жизнь подход. Тебе так удобно - ну и ладушки. А мне ваш деревянный меч который "типа, пакетный менеджер" кажется забавным.
	Ответить | Правка | ^ к родителю #291 | Наверх | Cообщить модератору

	313. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 15:02
	> А мне ваш деревянный меч который «типа, пакетный менеджер» кажется забавным. да на здоровье. вообще, в слаке штатно есть post-install скрипты, а зависимости опциональны, и для них написан slapt-get — как надстройка над стандартными пакетными утилитами. другое дело, что если человек выбрал слаку — то он, скорее всего, этим пользоваться всё равно не станет. основной же посыл был в том, что «я сам не работал, но мне сосед рассказал, и я осуждаю» — не очень умная позиция. особенно в спорах с тем, кто использует слаку больше десяти лет, и явно знает систему сильно лучше.
	Ответить | Правка | ^ к родителю #311 | Наверх | Cообщить модератору

	319. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:03
	> да на здоровье. вообще, в слаке штатно есть post-install скрипты, а зависимости > опциональны, и для них написан slapt-get — как надстройка над стандартными > пакетными утилитами. другое дело, что если человек выбрал слаку — то > он, скорее всего, этим пользоваться всё равно не станет. Ну дык слаку пользуют обычно олдскульщики, которые удобствами не избалованы. Так, по наблюдениям. Осталось еще пробубнить что-то типа "да нафиг надо этот ваш JTAG, вот тумблеры на шине с кнопкой пошаговой отладки - это труЪ" :). > основной же посыл был в том, что «я сам не работал, но > мне сосед рассказал, и я осуждаю» — не очень умная позиция. Оценить то или иное решение и его (не)соответствие пожеланиям к решениям такого класса можно и не становясь супер-гуру в конкретном решении которое все-равно будет отсеяно как неподходящее на самой ранней стадии. > особенно в спорах с тем, кто использует слаку больше десяти лет, > и явно знает систему сильно лучше. Так я вроде и не пытаюсь тебя твоей слаке обучать :). Просто попытки бряцания тем что гольный тарбол без нишиша это лучший формат для пакетов вызывает у меня некоторое недоумение: технических аргументов "за" не приведено, а некоторые очевидные "против" я могу и сам придумать на лету, чисто на основании моих знаний форматов файлов и их сильных и слабых мест.
	Ответить | Правка | ^ к родителю #313 | Наверх | Cообщить модератору

	320. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 20:10
	> Ну дык слаку пользуют обычно олдскульщики, которые удобствами не избалованы. наоборот. как раз удобствами мы очень избалованы. а вот от свистелок и перделок нас тошнит. > наблюдениям. Осталось еще пробубнить что-то типа «да нафиг надо этот ваш > JTAG, вот тумблеры на шине с кнопкой пошаговой отладки — это > труЪ» :). ну, про jtag я промолчу, а вот у gdb, например, полезность с моей точки зрения очень небольшая. в том плане, что он хорошо подходит для ковыряния кородампов. > Оценить то или иное решение и его (не)соответствие пожеланиям к решениям такого > класса можно и не становясь супер-гуру в конкретном решении которое все-равно > будет отсеяно как неподходящее на самой ранней стадии. особенно если думаешь, что оно только вот такое, и никаких дополнительных фич нет вообще (и что их надо руками корячить с нуля). > Так я вроде и не пытаюсь тебя твоей слаке обучать :) тем не менее о слаковых пакетных менеджерах зачем-то высказываешься. > попытки бряцания тем что гольный тарбол без нишиша это лучший формат > для пакетов вызывает у меня некоторое недоумение он *достаточный* в большинстве случаев. особенно если учесть, что техника сейчас весьма шустрая, и добыть метаданные из тарбола не особая проблема. впрочем, стандартные слакотулзы отлично понимают и случай, когда метаданные лежат рядом с пакетом в обычном текстовике: это для тех, кого не устраивает скорость «добычи». > технических аргументов «за» не приведено kiss. я, опять же, нигде не говорил, что тарбол — лучший формат. но, как уже сказал выше, он достаточен для большинства случаев.
	Ответить | Правка | ^ к родителю #319 | Наверх | Cообщить модератору

	337. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 02:15
	> наоборот. как раз удобствами мы очень избалованы. У вас там довольно специфичное понимание удобств :). "Зато я могу сходить в мой сортир независимо от выходок коммунальщиков!". Ну да, фиг оспоришь. > а вот от свистелок и перделок нас тошнит. Просто особо упертые олдскульщики считают свистелками и перделками почти все что выходит за пределы черно-зеленого терминала на RS232. Ну так, если утрировать немного :). > ну, про jtag я промолчу, Кстати раз уж ты про GDB - он умеет с ним работать, ага. Вот такие вот навороты - можно трэйсить состояние софта в некоем чипе по out of band интерфейсу :). Иногда может быть полезно. > а вот у gdb, например, полезность с моей точки зрения очень небольшая. > в том плане, что он хорошо подходит для ковыряния кородампов. Не совсем понимаю как без дебагера понять где сложная программа факапнулась. Ну да, устранение багов класса "крах" и прочего веселья - совсем такая небольшая польза, чо :) > особенно если думаешь, что оно только вот такое, и никаких дополнительных фич > нет вообще (и что их надо руками корячить с нуля). И что характерно, чаще всего как-то так и оказывается. Ну и кроме >> Так я вроде и не пытаюсь тебя твоей слаке обучать :) > тем не менее о слаковых пакетных менеджерах зачем-то высказываешься. Затем что если некто полагает что трекинг зависимостей это опционально и чисто для галочки - мне с ними все понятно. Для меня это не просто mandatroy, для меня это ключевой момент в пакетном менеджере, очень сильно разгружающий меня от системной рутины. А у слакваристов как ты сам сказал - это побочный сценарий, до кучи. Ну а как работают побочные сценарии в софте - я в курсе: не первый год в индустрии разработки ПО :). В таких случаях обычно обнаруживается что культурная комнатка с унитазом как бы есть, но питальник к насосу для откачки результатов - не подсоединен. Потому что все уже привыкли пользоваться милым сердцу скворечником во дворе :) >> попытки бряцания тем что гольный тарбол без нишиша это лучший формат >> для пакетов вызывает у меня некоторое недоумение > он *достаточный* в большинстве случаев. Весьма спорный тезис, имхо. Просто потому что формат тарбола не подразумевает быстрого извлечения из него частичных данных. Значит метаданные по быстрому вынуть будет не судьба. А это уже означает очень характерный набор проблем и соответствующую коррекцию сценариев использования. > особенно если учесть, что техника сейчас весьма шустрая, Это не повод делать себе крупную гадость на уровне базовой алгоритмики. > и добыть метаданные из тарбола не особая проблема. Угу, так и представляю себе парсинг 20К пакетов с чуть ли не полной распаковкой вообще всей этой кипы. Оптимальность такого подхода поражает воображение. Как раз в этом плане те же deb-пакеты смотрятся очень здраво: мелкий файлик с метаданными отдельно лежит и его адресно и быстро выцепить без распковки основного тарбола на 100500 Мб очень даже можно. > впрочем, стандартные слакотулзы отлично понимают и случай, когда метаданные > лежат рядом с пакетом в обычном текстовике: это для тех, кого не устраивает скорость «добычи». Меня также совершенно не устраивает гадеж в файловую систему какими-то лишними файлами которые мне самому в 99.9% - нафиг не упали. Я нахожу чертовски логичным что все что надо - лежит в пакете, но при необходимости достается оттуда по быстрому. А для полной красоты - еще и индексится в базе чтобы ускорить некоторые операции. >> технических аргументов «за» не приведено > kiss. Это уже звучит разумнее, однако почему-то почти никто не ходит пешком из питера в москву. Хотя идти пешком как бы вроде проще чем содержать целую железную дорогу с поездами и большой инфраструктурой. Наверное, кроме простоты есть еще параметры того что в результате получилось. > я, опять же, нигде не говорил, что тарбол — лучший формат. Ну вот на мое мнение, тарбол как формат пакетов - примерно как деревянный "костотряс" в роли велосипеда. Т.е. как-то и это поедет, конечно. Вопрос только в удобстве ездока. > но, как уже сказал выше, он достаточен для большинства случаев. Ну как бы у всех свои понятия о достаточности и большинстве. Мне вот например удобен трекинг зависимостей в 99.9% случаев и тулса с мощными средствами для всего этого. А в оставшихся 0.1% случаев - окей, 2 пакета из 2000 я так и быть вручную заоверрайдить могу. Если это реально потребуется.
	Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

	206. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:40
	> Хм. Слаководы вполне себе живут без PAMа, потому что им гуру запретил. потому что оно нам нафиг не надо. но ты, конечно, продолжай рассказывать чушь про слаку: чем больше про слаку чуши расскажут, тем меньше дебилов к нам придёт. вот маркова бы ещё кто забрал…
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	209. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 19:52
	>вот маркова бы ещё кто забрал… Покайсо, и избавит тебя Господь от наказания за грехи твоя... Либо терпи, ибо сказано в ман^W Писании - Господь не дает вам испытаний, кои не силам вашим.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	212. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+2 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 21:25
	> потому что оно нам нафиг не надо. Что вам надо, а что нет - решать не вам, а Патрику. Ибо воистину.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	213. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 21:27
	> Что вам надо, а что нет - решать не вам, а Патрику. > Ибо воистину. За кого-то решает Патрик, за кого-то Леннарт, за кого-то Марк. Но все, сцуко, как один, кричат "Мы не хомячки, мы умеем думать своей головой, а ты просто идиoт!!111".
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	276. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:32
	> Но все, сцуко, как один, кричат "Мы не хомячки, мы умеем думать > своей головой, а ты просто идиoт!!111". Ну так все правильно. Линух же не винда или макось где все гвоздями приколочено. Можно и дистр наиболее похожий на желаемое выбрать, и быстренько его довести до желаемого вида потом. И никакой Патрик, Леннарт или Марк не сможет оспорить например вынос некоего пакета пакетным менеджером. У них чисто технически такой возможности нет :) Удобство оверрайда может варьироваться. Но право на оверрайд и рукоятки для оного есть. Кто ими сможет пользоваться и насколько это будет удобно - второй вопрос. Но - можно, если хочется. Да, придется поработать. Но это по любому придется - никто не знает что нужно вам и вероятность что лично под вас сделают софт устраивающий в 100% случаев - крайне низкая.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	221. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 22:00
	>> потому что оно нам нафиг не надо. > Что вам надо, а что нет — решать не вам, а Патрику. меня не обещали зверски убить, если я сменю дистрибутив или пересоберу пакеты так, как мне понадобится. так что решать мне, просто мои предпочтения в основном совпадают с предпочтениями маинтайнеров слаки.
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	228. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 01:36
	У тебя в основном нет предпочтений. За тебя предпочитают мейнтейнеры слаки :)
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	229. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 01:39
	как у тебя пердак-то жжот.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	233. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 02:26
	> как у тебя пердак-то жжот. У меня? С чего бы? Мои религиозные чувства не были оскорблены (да и нельзя их оскорбить, ввиду их отсутствия). А вот с твоими чувствами обошлись весьма гадко, это да. И ты тут же с дымящимся хвостом побежал доказывать, что жжет вовсе не у тебя :)
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	235. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 02:35
	>> как у тебя пердак-то жжот. > У меня? С чего бы? а я откуда знаю? пердак-то у тебя дымится.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	240. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 03:04
	> а я откуда знаю? пеpдак-то у тебя дымится. Фу, как неуклюже. Напоминаешь упоpотого бздишника в соседнем треде - над ним уже в открытую стeбутся, а он все тыкает пальцем и визжит "у тебя батxерт! у тебя батxерт!!1". Походу, все остальные слова просто из головы вылетели. Под воздействием подогрева снизу :)
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	242. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 03:05
	>> а я откуда знаю? пеpдак-то у тебя дымится. > Фу, как неуклюже. я же не виноват, что ты дурак.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	244. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 03:12
	> я же не виноват, что ты дурак. То, что мне, дураку, удалось заставить тебя, такого умного, добровольно прыгнуть в помойку и покувыркаться там - уже неплохо. Смех действительно продлевает жизнь. А у тебя, к тому же, и так природная склонность, поэтому не такой уж я и злодей :)
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	246. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 03:16
	где я сказал «злодей»? я сказал «дурак». ты читать, что ли, не умеешь?
	Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

	248. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 03:25
	Вопрос о моем злодействе тебя не касается. Это так было, замечание на полях. Успокойся уже, валокординчику попей. А то бессонница замучает, завтра будешь вялый и несмешной :)
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	250. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 03:32
	больше заискивающих смайлов давай.
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	266. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:04
	> где я сказал «злодей»? я сказал «дурак». ты читать, что ли, не > умеешь? Арису, ты знаешь, а дураком-то ты выглядишь.
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	277. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:34
	> Арису, ты знаешь, а дураком-то ты выглядишь. А вы еще тупее выглядите. У arisu хотя-бы аргументы просматриваются. А у вас только шакалье тявканье.
	Ответить | Правка | ^ к родителю #266 | Наверх | Cообщить модератору

	287. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 13:36
	аргументы у меня есть всегда, просто большинство «оппонентов» показывают свой уровень буквально парой комментариев. после чего вести какую-то аргументированую дискуссию я смысла уже не вижу.
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	285. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 13:34
	> Арису, ты знаешь, а дураком-то ты выглядишь. мне можно, я и вправду дурак. хоть и гений.
	Ответить | Правка | ^ к родителю #266 | Наверх | Cообщить модератору

	205. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:39
	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.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

33. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от AlexAT (ok) on 07-Июл-13, 17:09
Вангую взлёт SQLite.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	91. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 00:46
	> Вангую взлёт SQLite. Так оно уже давно взлетело. В браузерах, например.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	105. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:44
	> Так оно уже давно взлетело. В браузерах, например. Только слопупочит немилосердно на некоторых операциях без костылей. Хотя слоупочить - это в целом умение скулей вообще :)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	114. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 07:20
	Да там не из-за SQL слоупочность. Там во время записи блокируется весь файл целиком, параллельная запись невозможна (мб что и изменилось, мог отстать от жизни).
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	153. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:49
	> Да там не из-за SQL слоупочность. Там во время записи блокируется весь > файл целиком, параллельная запись невозможна (мб что и изменилось, мог отстать > от жизни). Сами по себе множественные writer'ы - это уже заявка на большой и крутой двигун БД, к тому же на мощной дисковой подсистеме (обычному единичному механическому диску удобнее  как раз 1-поточная работа в общем случае). Собственно BDB обычно юзают как глупую но быструю базу ключ-значение, которая может быстро выколупывать нужные записи. Намного быстрее чем это светит скулю. Другое дело что я не понял чем этот BDB так всем понравился. Ну вон токийский кабинет есть, под LGPL. Тоже ключ-значение, тоже быстрый. Даже быстрее BDB вроде. Ну хотя у BDB апи достаточно логичное + в свое время их разработчики были достаточно контактабельны, как сейчас - не знаю, а в свое время они мне помогли с рядом багов справиться. В целом sleepycat были достаточно прикольной такой конторкой, потом их оракл скушал. И вроде даже ничего особо не испортил как ни странно. Видимо столь мелкая база им не особо интересна и давиться жабой там негде особо было.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	223. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Июл-13, 22:33
	>  Ну вон токийский кабинет есть, под LGPL. это  же плюсовое дерьмо на шаблонах, +1МБ к бинарю и прочие плюсовые пакости. Нахер его. bdb однозначно лучше.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	226. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+2 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 23:04
	>>  Ну вон токийский кабинет есть, под LGPL. > это  же плюсовое дерьмо на шаблонах ты попутал tokyo cabinet и kyoto cabinet. а ещё qdbm есть.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	278. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:40
	> это  же плюсовое дерьмо на шаблонах, Вас жестоко глючит, токийский кабинет на голом си написан :) > +1МБ к бинарю и прочие плюсовые пакости. Это наверное было про kyoto cabinet. Ну да, tokyo, kyoto, какая папуасу разница? :) > bdb однозначно лучше. У bdb кода больше чем в токийском кабинете, пожалуй. И он быстрее. И апи у него попроще, пожалуй. Хотя в целом bdb довольно приятная штука, imho.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	104. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:43
	> Вангую взлёт SQLite. Сравнил попу с пальцем. А ничего что скулайт не умеет kev-value, в отличие от? А скуль - тормозной и опасность иньекций к тому же есть. BDB в режиме SQL практически никто не юзает - их как базу key-value обычно пользуют, каковой они всегда и были. Скуль они потом до кучи немного прикрутили и большинству пользователей BDB он нафиг не упал.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	113. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 07:19
	Я в курсе. Но из embedded движков логичнее выбрать SQLite, если конечно параллелизм на записи не требуется. И - да - любой реляционный движок легко позволяет сэмулировать key-value storage :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	117. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–5 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 09:57
	> Berkeley DB входит в числе базовых библиотек, от которых зависят многие пакеты. В связи с этим поставлен вопрос, допустима ли поставка базовых библиотек под AGPLv3, так как связывание с AGPLv3-библиотекой приведёт к распространению лицензии AGPLv3 на все использующие данную библиотеку пакеты. Не ужели? да как они могли.. А вот когда gcc такую шутку провернул с libgcc - все дружно набрали воды в рот.. И ставили столмана..
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	124. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от klalafuda on 08-Июл-13, 10:46
	> Не ужели? да как они могли.. А вот когда gcc такую шутку провернул с libgcc - все дружно набрали воды в рот.. И ставили столмана.. RTFM однако: http://www.gnu.org/licenses/gcc-exception-faq.html Что впрочем не удивительно - быстрой смерти GCC после полного перевода рантайма на честный *GPL никому не нужно.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	128. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 11:36
	что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	129. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от klalafuda on 08-Июл-13, 11:44
	> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception. Я не в курсе деталей этой истории, но лично мне ничего удивительного в ней не видится. Полагаю, что сперва Столман & K решили как водится 'до основания а затем'. Но чуть позже трезвые товарищи по партии доходчиво объяснили им, что столь радикально делать не стоит. Иначе они останутся со своим полностью свободным GCC в гордом одиночестве в том числе без толстых спонсоров. Благо, конкурентов GCC хватает.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	137. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 14:06
	Вот вот.. Пусть делают свой самый свободный компилятор.. А то "ложечки нашлись - но ведь осадочек остался" ? Что еще эта компания сделает? Хотя вот разработчики Debian оказались не рады AGPL v3.. почему - не подскажете ?
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	143. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:25
	> Хотя вот разработчики Debian оказались не рады AGPL v3.. почему - не подскажете ? удаки и идоры потому что. Сегодня лишний раз в этом убедился (да, и это никак не относилось к лицензионным вопросам).
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	155. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от northbear (??) on 08-Июл-13, 15:56
	> Благо, конкурентов GCC хватает. Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать. Но именно эта история спровоцировала бурное развитие Clang/LLVM. Видать Oracle патологически не способен учиться на чужих ошибках...
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	171. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:22
	>> Благо, конкурентов GCC хватает. > Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать. > Но именно эта история спровоцировала бурное развитие Clang/LLVM. наверно вы помните - что ядро Clang собирал уже давно. Но слишком много "программистов" не знаю слово "стандарт на язык", а пишут как привыкли/научили - с кучей компиляторо-зависимого кода. Могу больше сказать - попытка собрать ядро при помощи gcc с флагами -pedantic обречена на неудачу - в основном из-за такой вот кривизны кода.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	231. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от northbear (??) on 09-Июл-13, 02:25
	> наверно вы помните - что ядро Clang собирал уже давно. Давно это 2-3 года? Сравните например с возрастом проекта GNU GCC (1987 год) или Linux-ядра (1991 год). Это то, что я называю словом давно. А Clang еще младенец, хоть и невероятно продвинутый...
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	175. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от klalafuda on 08-Июл-13, 16:29
	> Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать. Но именно эта история спровоцировала бурное развитие Clang/LLVM. Как раз сборка ядра - это совсем не показатель. Его можно собирать всем, чем угодно. По всей очевидности все той же GCCой под какой бы лицензией оно не шло. Это никак не повлияет на проекты в userland. А вот выпуск рантайма GCC под AGPL - это уже, простите, совсем другой коленкор. Это напрямую затрагивает закрытые проекты. У них не останется никакого выбора, кроме как смотреть на альтернативы. И если Clang сможет предоставить вменяемую реализацию компилятора C++, то это будет более чем реальная альтернатива GCC и переход коммерческих проектов с GCC на тот же Clang будет лишь вопросом времени причем весьма скорого. С учетом того, что GCC - это пожалуй основной реально востребованный проект GNU, подобный переход очень и очень больно ударит по FSF. В том числе и финансово. У многих крупных коммерческих вендоров отпадет сам смысл с ними особо возиться. Оно FSF такое надо?
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	234. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от northbear (??) on 09-Июл-13, 02:35
	> Как раз сборка ядра - это совсем не показатель. Его можно собирать > всем, чем угодно. Я молча развожу руками... Может продемонстрируете?
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	236. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 02:36
	tcc когда-то собирал ядро прямо при загрузке. было забавно. интересно, способен ли он до сих пор на такой фокус?
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	239. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от northbear (??) on 09-Июл-13, 03:03
	> tcc когда-то собирал ядро прямо при загрузке. было забавно. > интересно, способен ли он до сих пор на такой фокус? ТССBOOT собирал адаптированные исходники собранные в ISO-образ. ТСС ничего не знает про расширения системы команд x86 типа SSE/SSE2. Я уже не говорю про код KVM в ядре...
	Ответить | Правка | ^ к родителю #236 | Наверх | Cообщить модератору

	241. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 03:05
	вообще-то с тех пор tcc значительно подрос. и да: ядро таки может работать и без sse, и даже без kvm.
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	279. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:43
	> работать и без sse, и даже без kvm. Ну да, а еще можно руку ампутировать. Печатать на клавиатуре и одной рукой можно. Зачем тебе лишние запчасти?!
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	290. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 13:45
	> Ну да, а еще можно руку ампутировать. Печатать на клавиатуре и одной > рукой можно. Зачем тебе лишние запчасти?! а зачем мне в ядре sse и kvm? не «зачем оно вообще надо?», а «зачем оно лично мне?»
	Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

	305. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:41
	> а зачем мне в ядре sse и kvm? не «зачем оно вообще > надо?», а «зачем оно лично мне?» Зачем лично тебе - не знаю, за отсутствием телепатического устройства. Лично мне оно например затем что 1) Я запускаю KVMные виртуальные машины. Очень удобно для системокрушильных экспериментов. Убабахать в процессе виртуалку - одно, ее к снапшоту откатил и порядок. А раздестроить нето в основной системе - да ну нафигЪ :) 2) С SSE намного быстрее работает код для RAID5/6 и шифрование, например. Буквально кипа модулей ядра при возможности юзает самые современные наборы инструкций. И да, знаешь, там кроме всего прочего в dmesg пишется результат бенчмарков. И я имею отметить что от новых инструкций есть толк: самые забористые реализации алгоритмов на новейших командах могут делать старые SSE в несколько раз. А без SSE - вообще сталинград. А просадить половину криптографии и кода рэйдов в разы, system-wide - категорически дурная идея в общем случае. Ну то-есть, как я уже сказал - можно печатать и 1 рукой. Но медленнее и вообще неудобно.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	316. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от linux must __RIP__ on 09-Июл-13, 17:14
	> 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 системе.
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	321. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:21
	> вы точно уверены в своих словах? Я уверен что я в состоянии прочитать 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. Это ваша больная фантазия разбушевалась, я тут не при чем :).
	Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

	258. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от klalafuda on 09-Июл-13, 11:16
	> Я молча развожу руками... Может продемонстрируете? "Его можно собирать всем, чем угодно." с точки зрения лицензии тулчейна и его обвязки. Это никак не повлияет на требования к лицензированию программ в userland-е.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	272. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Led (ok) on 09-Июл-13, 12:22
	>> Как раз сборка ядра - это совсем не показатель. Его можно собирать >> всем, чем угодно. > Я молча развожу руками... Может продемонстрируете? icc, open64, tcc
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	181. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 16:36
	>> что удивительно - это 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.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	217. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 21:49
	>>> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception. >> Я не в курсе деталей этой истории, но лично мне ничего удивительного >> в ней не видится. Полагаю, что сперва Столман & K решили > Спасибо, что спросили! :) > Исключение про рантайм там было чуть не с созданья мира. > "Просто" при переходе на GPLv3+ его не пофиксили под все [новые] "крайние" > случаи. Это было сделано _сразу же_ по обнаружении (=рипорте о) проблемы, > в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий. вы серьезно верите что поменяв лицензию - народ не задумывался о том что менять надо и linking exception? юристы типа "забыли"? вам самому не смешно? вы уверены что больше ничего не забыли такого что выйдет боком через N лет ? Ну да - а пофиксили когда их макнули в это дерьмо - что так дела не делают.. а если бы не ткнули - так бы и работало все.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	224. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 22:49
	>> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий. > вы серьезно верите что поменяв лицензию - народ не задумывался о том Мартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала. Святой отец, б., "веруешь ли", да, "веруешь ли".
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	262. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 09-Июл-13, 11:54
	>>> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий. >> вы серьезно верите что поменяв лицензию - народ не задумывался о том > Мартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала. > Святой отец, б., "веруешь ли", да, "веруешь ли". а по теме сказать чего-то есть? я вижу только веру в великого..
	Ответить | Правка | ^ к родителю #224 | Наверх | Cообщить модератору

	280. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:45
	> а по теме сказать чего-то есть? я вижу только веру в великого.. Да какая там вера? Обычный жирный троллинг всяких глупых личностей. Они, кстати, ведутся. Хоть и жирнота, казалось бы. Все-таки Митрофанов - талант. Так жирно потроллить чтобы на это какой-то лузер еще и купился - это талант иметь надо :)
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	154. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:54
	> Я в курсе. Но из embedded движков логичнее выбрать SQLite, Как по мне я вижу минимум 2 причины НЕ выбирать его: 1) SQL априори тормозной и его профайлинг может местами превратиться в полный головняк. 2) Бодаться с SQL иньекциями нравится не всем. В базу key-value такого плана заиньектить левак невозможно. Поэтому базы key-value по своему прекрасны. И никак не заменяются скулайтом, при всем уважении к оному. То-есть, скулайт в принципе не сможет предоставить сравнимую производительность + отсутствие проблем с иньекциями в SQL запросы от всяких "бобби тэйблсов". А превращать полпрограммы в фильтр т.к. "злоумышленник может унести солонку, назвавшись Бобби Тэйблсом" совершенно не прикольно. > движок легко позволяет сэмулировать key-value storage :) Вот только скорость работы что-то не эмулируется. И иньекции станут отдельным пунктом головняка у програмера.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	159. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 15:59
	> В базу key-value такого плана заиньектить левак невозможно И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set. > Вот только скорость работы что-то не эмулируется. А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	166. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:17
	> И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set. Ты издеваешься или как? Можно взять готовое решение которое работает быстро и безграбельно, а можно др@читься с выписыванием костылей самому + просесть в скорости. Нафиг надо такое "счастье"? В нормальном виде сие должны были делать по людски разработчики скулайта, предоставив простое и низкоуровневое апи к его фактической реализации хранилища. Но это не было их целью, как соедует из названия. У них SQL головного мозга и баста. Если тебе нравится забивать гвозди микроскопом - флаг тебе в руки делать key-value из скулайта. А мне если уж AGPL так сильно дорогу перейдет, я какой-нить токийский кабинет возьму скорее. И да, обычно в таких базах можно выбирать довольно низкоуровневые параметры стоража, которые иногда довольно сильно роялят. В частности - хэш-таблица, б-дерево, etc. Они разные по свойствам и в зависимости от ситуации - оптимальнее или так, или эдак. А в скулайте такое вообще хрен выберешь вообще. > А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать. Я не собираюсь бросать все и подрываться изучать новый ЯП (SQL) на уровне супергуру который умеет запросы профайлить. Тем более что там IIRC нет относительно низкоуровневых опций управления логикой стоража на уровне самых основ технологий хранения. А иногда удачный выбор таких опций может скорость в разы поднять. На скулайте придется пыхтеть в разы больше, а скорость будет в разы ниже.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	168. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 16:20
	> Ты издеваешься или как? Да нет. Мне просто ехать, а не шашечки.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	172. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:23
	>> Ты издеваешься или как? > Да нет. Мне просто ехать, а не шашечки. ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB ?
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	179. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от klalafuda on 08-Июл-13, 16:35
	> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB ? Вы таки серьезно считаете, что в том же SQLite на бакенде текстовый файл со строчками INSERT INTO Table VALUES (1, "John"), (2, "Doe") ?
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	183. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:37
	Нет, там конечно бинарный стораж, но простой и быстрой дорожки его дернуть не дадено, равно как и управлять его базовыми свойствами. А общаться с ним через призму парсера скуля - совершенно отдельная история. Парсер потратит немало времени на разбор конструкции и не факт что это будет оптимально. С другой стороны хорошая база ключ-значение как правило укладывается в всего 2 дисковые операции на извлечение записи + минимальная нагрузка на проц.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	199. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 17:57
	> Парсер потратит немало времени на разбор конструкции и не факт что > это будет оптимально. Два слова: "prepared statements" - о чём-нибудь говорят?
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	218. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–3 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 21:50
	>> Парсер потратит немало времени на разбор конструкции и не факт что >> это будет оптимально. > Два слова: "prepared statements" - о чём-нибудь говорят? говорит - что исполнение байт кода - всегда дольше чем просто поиск по базе key-> value. Кстати как там с SQLite с поддержкой транзакционного стораджа?
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	252. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 07:16
	> говорит - что исполнение байт кода - всегда дольше чем просто поиск > по базе key-> value. Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными. В остальных случаях накладные расходы будут несущественны. Не забывайте, что у KV обычно всё атомно плохо с индексацией и произвольным поиском. Плюсы от возможности вести поиск по связям и наборам полей могут и перевесить минусы от наличия разборщика запросов. Не везде, естественно. Во всяком случае, Subversion уже использует SQLite в клиентской части. Очевидно, осознали плюсы. > Кстати как там с SQLite с поддержкой транзакционного стораджа? А там иных не бывает... огромная проблема SQLite - необходимость блокирования всего файла при записи. Коммиты у SQLite атомарные, поэтому с конзистентностью всё более-менее. Не хуже, чем у BDB, во всяком случае.
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	257. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от klalafuda on 09-Июл-13, 11:05
	> Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными. Ага. Особенно если нужно обработать данные из таблички с парой-тройкой десятков-сотен миллионов записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	263. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 09-Июл-13, 11:56
	>> Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными. > Ага. Особенно если нужно обработать данные из таблички с парой-тройкой десятков-сотен миллионов > записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там. не надо издеваться с детей :-) вот к примеру filldir() вполне себе выполняется внутри inner loop у dx dir аналогом которого является bdb и таких примеров чуть более чем дофига..
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	270. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 12:09
	> не надо издеваться с детей :-) вот к примеру filldir() вполне себе > выполняется внутри inner loop у dx dir аналогом которого является bdb > и таких примеров чуть более чем дофига.. Ну... ручки-то они - вона какие...
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	330. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 23:55
	Вот, лакмусовая бумажка на крап-дезигнеров сработала. Если у вас случилась ситуация (shit happens, yeah), что вам надо из KV более одного раза за время жизни с последнего апгрейда вот так вот выгрести и обработать сотню миллионов записей - "поздравляю, Шарик, вы балбес"... выбор KV для задачи не то, что не оправдан, а вообще симптоматичен.
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	339. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 10-Июл-13, 02:24
	> задачи не то, что не оправдан, а вообще симптоматичен. Тем не менее, справедливости ради - сиквельная будет вычитывать записи ничуть не хуже самопала. А при шит дизайнере с select * from, столь типичном для скрипткиддисов... - скульная база натурально все сотни миллионов записей будет лопатить ничуть не хуже. Грамотно юзать скуль и понимать во что по факту оно будет трансформировано (дисковая активность, etc) умеет сильно немного народа - это отдельный класс крутых DBA/опытных SQL программеров, в общем свой заводик по производству ракет, со своим рокетсайнсом и инженерами. Вот так с наскока это взять вообще не варинт. Грамотно юзать k/v на порядок проще. Просто потому что он примитивный.
	Ответить | Правка | ^ к родителю #330 | Наверх | Cообщить модератору

	338. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 10-Июл-13, 02:20
	> записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там. Если тебе приходится это делать с K/V - ты что-то делаешь не так. Совсем не так.
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	265. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от linux must __RIP__ on 09-Июл-13, 12:00
	>> говорит - что исполнение байт кода - всегда дольше чем просто поиск >> по базе 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 - можно делать комиты в несколько таблиц внутри одной транзакции без необходимости лочить базы. Как видимо это явно "лучше".
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	281. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:51
	> Два слова: "prepared statements" - о чём-нибудь говорят? Здравый смысл и понимание алгоритмов говорят мне что лукап по b-дереву или хэш-таблице априори быстрее чем нечто аналогичное + пакости от парсера невъ...нного языка и вагон костылей для их воркэраундинга. Но ты в своем праве делать из сиквельной базы key-value. Но лично я не понимаю в чем пойнт сначала сильно усложнить себе жизнь, сначала донавесив поверх хранилища парсер, а потом героически воевать с ветряными мельницами, пытаясь отделаться от его проблем, чтобы в результате ... получить нативное представление сущностей в хранилище? Да ты больной. Проще сразу не навешивать парсер чем воевать с его фирменными граблями типа тормозов, иньекций и прочих радостей жизни.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	306. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 14:43
	Ты так и не понял сути. Основная проблема - не в том, что нет KV на замену, а в том, что KV пихают даже туда, где он в принципе убыточен. А речь изначально шла о том, что в ряде проектов BDB можно заменить на embedded SQL/embedded NoSQL. Чего накинулся - непонятно.
	Ответить | Правка | ^ к родителю #281 | Наверх | Cообщить модератору

	322. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:33
	> даже туда, где он в принципе убыточен. Такое наверное бывает, но это можно делать из чувства мазохизма разве что. Это скорее SQL нынче пихают даже туда где он нафиг не упал и только все портит. Вот вы - яркий показатель, btw. > А речь изначально шла о том, что в ряде проектов BDB можно > заменить на embedded SQL/embedded NoSQL. Можно != нужно. Сам по себе NoSQL термин - вообще ни о чем. BDB тоже NoSQL. Хотя и SQL там в принципе есть, правда я ни разу не видел чтобы им кто-то пользовался, но потенциально - можно :). >  Чего накинулся - непонятно. То что довольно странно предлагать самосвал как замену микроавтобусу, с аргументом "если как следует поорудовать автогеном, можно кузов отпилить и заменить на салон микроавтобуса". Спору нет - все это можно. Только рассматривалось целевое использование k/v ака быстрый и простой доступ к записям, возможно в достаточно большом количестве. Там SQL не только нафиг не упал но и все испортит. А то что кто-то мог заюзать свой микроавтобус для перевозки песка из карьера - ну так кто ему доктор?
	Ответить | Правка | ^ к родителю #306 | Наверх | Cообщить модератору

	198. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 17:56
	> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в > BDB ? Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того, что работа с BDB - не основная операция.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	219. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 21:50
	>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в >> BDB ? > Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того, > что работа с BDB - не основная операция. у кого как :-)
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	243. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 03:07
	> у кого как :-) Ну, у юнит-тестов BDB все, конечно, иначе...
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	282. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:56
	> Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того, > что работа с BDB - не основная операция. А это как бы весьма зависит от. Такие базы ставят там где скорость работы с базой все-таки интересовала. При этом сознательно идут на упрощение абстракций и их примитивизацию в пользу скорости работы + можно не париться экранированием (которое для больших объемов данных опять же тормознет все). Все-равно заиньектить в базу принимающую любые данные как  ключ и значение технически невозможно.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	307. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 14:46
	> Такие базы ставят там где скорость работы с базой все-таки интересовала. Особенно в том же SVN, агаугу. Или в PAM. Там и SQL нахрен не впёрся, конечно, но в целом от скорости работы с самим форматом базы там ничего не меняется - не там основная нагрузка.
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	323. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:39
	> Особенно в том же SVN, агаугу. Ой, как они им пользуются - я без понятия. Не интересуюсь некромансией. В git например свой самопальный кастомный формат хранения объектов везде, т.к. все это очень чувствительно к скорости. > Или в PAM. Как бы в таких применениях ситуация бывает разной. Какой-нибудь контроллер домена например может обслуживать десятки тысяч авторизаций в секунду. И я не вижу ни одной валидной причины по которой PAM имел бы право умирать под такими нагрузками. Лучше пусть запас производительности будет чем наступит ж@па. > Там и SQL нахрен не впёрся, конечно, но в целом от скорости работы с > самим форматом базы там ничего не меняется - не там основная нагрузка. Зато прилетевший на что-то типа контроллера домена скуль иньекшн от бобби тэйблса энтерпрайзникам точно понравится :). Ибо раздестроить нечто типа активной директории или ее аналога 1 запросом - сказочная мечта любого кулхацкера :).
	Ответить | Правка | ^ к родителю #307 | Наверх | Cообщить модератору

	253. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 07:22
	> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в > BDB ? Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В SQL-based движках в основном всё те же btree :) на подложке. А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на большие расстояния. Да и просто практичнее в плане удобства. Доехать-то доедешь, но за@#$шься прилично. Там, где структура данных достаточно простая, и отношение объема данных к объёму единственного ключа максимально - лучше KV не придумать. Где посложнее - использование KV или прямых методов доступа к сторейджу выльется в феерические костыли, которые уже давным-давно сделаны в реляционных движках, и сделаны лучше. Вопрос в применимости. Когда-то embedded-движков RDB не было, и все юзали что попало, изобретая велосипеды для поиска в KV-сторейдже к примеру. Сейчас их вагон, и отказываться от удобства - тупо.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	269. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от linux must __RIP__ on 09-Июл-13, 12:06
	>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в >> BDB ? > Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В > SQL-based движках в основном всё те же btree :) на подложке. Замечена попытка ухода в сторону. Вами был выдвинут тезис что реализация KV стораджа средствами SQLite по меньшей мере не медленее чем  BDB а то и быстрее. Вот отсюда и вопрос - вы серьезно считаете что скорость выполнения предкопилированых sql запросов в sqlite будет дотягивать до скорости поиска по b-tree для BDB ? > А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на > большие расстояния. Да и просто практичнее в плане удобства. Доехать-то доедешь, > но за@#$шься прилично. Зависит от загруженности города. Я знаю много городов где на велосипеде доехать быстрее. > Там, где структура данных достаточно простая, и отношение объема данных к объёму > единственного ключа максимально - лучше KV не придумать. Где посложнее - > использование KV или прямых методов доступа к сторейджу выльется в феерические > костыли, которые уже давным-давно сделаны в реляционных движках, и сделаны лучше. Может вы забыли что для правильного использования SQL надо приводить к НФ 3? а тогда большой разницы с поиском по ключу в KV не будет. хотя да.. современная молодежь забывает о нормальных формах БД. > Вопрос в применимости. Когда-то embedded-движков RDB не было, и все юзали что > попало, изобретая велосипеды для поиска в KV-сторейдже к примеру. Сейчас их > вагон, и отказываться от удобства - тупо. Да да. А перегружать задачи не нужной функционостью - это ооочень правильно. И терять в скорости тоже.. как это похоже на современных программистов - которые вырезают гланды автогеном..
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	283. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 13:28
	> Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В > SQL-based движках в основном всё те же btree :) на подложке. Вот только сперва донавесить парсер, а потом путем длительной борьбы задеградировать его до "почти b-дерева" - бессмысленно и беспощадно. Куча времени будет убита ни на что! - Придется изучить SQL. - Придется изучить сколько времени и где тратится. - Придется очень хорошо раздуплять как оно план выполнения кроит и прочая. - И как это потом трансформируется в дисковую активность. - И как это "хакнуть" чтобы этот бредогенератор минимизировал свои операции и вообще интерференцию. - Придется делать экранирование. - Итоговая скорость даже в самом идеальном случае будет несколько хуже. В реальном случае, с разумными затратами сил, без месяца профилировки и войны с парсером/планировщиком выполнения - оно скорее всего сольет в несколько раз. > А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на > большие расстояния. При всем уважении, автомобиль не заменяет велосипед.
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	308. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 14:47
	> При всем уважении, автомобиль не заменяет велосипед. В 1% случаев - не заменяет. Попытки проехать на велосипеде от Москвы до хотя бы СПб - ну чего, флаг в руки.
	Ответить | Правка | ^ к родителю #283 | Наверх | Cообщить модератору

	324. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:40
	> В 1% случаев - не заменяет. Попытки проехать на велосипеде от Москвы > до хотя бы СПб - ну чего, флаг в руки. Да фигня вопрос! Кладем в багажный отсек поезда/самолета и едем :).
	Ответить | Правка | ^ к родителю #308 | Наверх | Cообщить модератору

	180. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:35
	> Да нет. Мне просто ехать, а не шашечки. Мне тоже. И мне совершенно не улыбается идея опилить сначала самосвал до легковушки а потом еще и удивляться - ой, а чего это он даже по идеальному шоссе выше 80 км/ч вообще никак? :)
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	201. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 19:00
	Я согласен, что для KV лучше использовать именно KV сторейджи. Но в приличном ряде случаев, а особенно там, где для KV применялся BDB - разница вряд ли будет ощутимой. Плюс вполне возможно, что польза/выигрыш от перехода на SQL с индексами и произвольными выборками будет больше, чем от собственно архитектуры KV. PS. Очепятался.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	286. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 13:35
	> Я согласен, что для KV лучше использовать именно KV сторейджи. Но в > приличном ряде случаев, а особенно там, где для KV применялся BDB > - разница вряд ли будет ощутимой. KV обычно применяется тем где надо быстро лопатить много записей в примитивном виде. Скуль в этом случае ничего кроме головняка вообще не даст. > Плюс вполне возможно, что польза/выигрыш от перехода на SQL с индексами > и произвольными выборками будет больше, чем от собственно архитектуры KV. В KV априори есть полный индекс по ключу, по другому оно просто работать не умеет :). Там негде выигрывать. Это и так одна из наиболее быстрых опций - непосредственный лукап в стораже без всякого промежуточного балласта. Скулю там негде выиграть по скорости, by design. По крайней мере в key-value применениях. Скуль имеет смысл для навороченных иерархий с таблицами и прочая - на KV придется сделать то же самое но через тот еще зад и самому. Но если KV уже поюзан - значит задача совсем не о том была.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	309. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 14:48
	> KV обычно применяется тем где надо быстро лопатить много записей в примитивном > виде. Скуль в этом случае ничего кроме головняка вообще не даст. При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	312. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 14:56
	> При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения. а это называется «мы узнали модный баззворд». если в задаче часто требуется какое-то навороченое фильтрование, для которого никак не получается вывернуться, зашив нужную информацию в ключи, то авторы промахнулись с инструментом.
	Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

	325. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:43
	> При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения. Да вы, я так смотрю, эксперт по забиванию гвоздей микроскопом. Вы умеете сватать и скуль туда где он не уперся, и kv там где с ним сложно. Тем не менее, некоторые k/v умеют сортировку записей и/или выборку диапазонов, если уж на то пошло. Насколько оно там подойдет в конкретном случае - вопрос номер два, смотреть надо. Но если подойдет - это будет круто и быстро, ибо все это на уровне нативного представления данных в стораже.
	Ответить | Правка | ^ к родителю #309 | Наверх | Cообщить модератору

	207. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:42
	> Я в курсе. Но из embedded движков логичнее выбрать SQLite, если конечно > параллелизм на записи не требуется. LMDB: http://symas.com/mdb/
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	289. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 13:43
	> LMDB: http://symas.com/mdb/ mmaped -> на 32-бит платформах лимитирована 4Гб. Это фэйл.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	299. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 14:10
	>> LMDB: http://symas.com/mdb/ > mmaped -> на 32-бит платформах лимитирована 4Гб. Это фэйл. скажи, что у тебя за база размером в терабайты? и что за приложение, которое требует, чтобы ко всем этим терабайтам был рандомный доступ всегда? и почему там key/value, когда такие базы явно требуют более сложных выборок? короче говоря, у тебя или понты ради понтов, или хреновое проектирование и неверно выбраный инструмент. алсо, если ты ворочаешь такими объёмами данных, то почему у тебя x86? наверняка там сервер с кучей RAM, и лимитировать одну задачу четырьмя гигабайтами как-то очень глупо.
	Ответить | Правка | ^ к родителю #289 | Наверх | Cообщить модератору

	303. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:33
	> скажи, что у тебя за база размером в терабайты? и что за > приложение, которое требует, чтобы ко всем этим терабайтам был рандомный доступ > всегда? и почему там key/value, когда такие базы явно требуют более сложных выборок? С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком примитивной и заменишь свою файловую систему на SQLную базу, ога :) > короче говоря, у тебя или пoнты ради пoнтов, или хрeновое проектирование и > неверно выбраный инструмент. Короче говоря, это просто ничем не обоснованный буллшит. Простая и быстрая база вполне может катить для применений где хранится сколько-то гб данных. Отличный пример таких баз - файловые системы, которые по сути оно самое и есть. Ну разве что заоптимизировано под свои специфичные нужды. А по общей логике - напрашивается чтобы тебя потроллить этим применением за излишне generic'овые высказывания :). > алсо, если ты ворочаешь такими объёмами данных, то почему у тебя x86? Алсо, я могу прицепить 2-терабайтный винч к вон той 32-битной ARMовской платке по sata. Ничему не противоречит. А вот какой-то совершенно идиoтский лимит нарисовавшийся на ровном месте - двигуну совсем не в плюс. Не, в целом смотрится любопытно, но вот это свойство все портит. Увы, я такое классифицирую как defective by design.
	Ответить | Правка | ^ к родителю #299 | Наверх | Cообщить модератору

	335. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 00:04
	> С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком > примитивной и заменишь свою файловую систему на SQLную базу, ога :) MS уже пыталась. Идея, кстати, неплоха, но опять же - не стоит ее везде лепить - только там, где нужен поиск по хреновой туче нечетких критериев.
	Ответить | Правка | ^ к родителю #303 | Наверх | Cообщить модератору

	340. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 02:35
	> MS уже пыталась. Но зафэйлили. И если уж на то пошло, у MS есть собственный весьма забористый ESE storage engine который они никуда выкидывать не собираются и он больше ориентирован на простую но быструю работу нежели на навороты а-ля скуль. Этот движок используется такими "незначительными" сущностями как active directory и exchange. При том что у MS, заметь, есть и сиквел-сервер, даже у MS хватает ума не впихивать это там где надо натурально быстрый доступ к базе без переусложнений которые бы реально потребовали скуль. Я конечно понимаю что если упереться рогом в свой долбаный скуль то кажется что мир крутится вокруг него. Но если разуть глаза - можно обнаружить немало интересных фактов, отличающихся от вашего представления о серебряных пулях. > Идея, кстати, неплоха, но опять же - не стоит ее везде лепить - только там, > где нужен поиск по хреновой туче нечетких критериев. В конечном итоге оказалось проще навесить внешний индексатор. И там тоже вроде как никаких скулей не пользуется. Вообще поражают потуги всучивать скуль во все щели, даже туда где он нафиг не уперся и создает только кучу проблем на ровном месте.
	Ответить | Правка | ^ к родителю #335 | Наверх | Cообщить модератору

	343. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 07:20
	> При том что у MS, заметь, есть и сиквел-сервер, даже у > MS хватает ума не впихивать это там где надо натурально быстрый > доступ к базе без переусложнений которые бы реально потребовали скуль. Имхо просто переделывать некому пока. А насчет SQL - он у них даже в WMI представлен весьма себе неплохо - где он имхо совершенно не нужен. > В конечном итоге оказалось проще навесить внешний индексатор. Да и работает он... как внешний индексатор... Многие функцию "поддержки поиска" тупо отключают сразу после инсталла, потому что именно так и реализован.
	Ответить | Правка | ^ к родителю #340 | Наверх | Cообщить модератору

	351. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 14:01
	> Имхо просто переделывать некому пока. Написать SQL сервак есть кому, написать ESE storage есть кому, а переделать некому? Как-то слишком притянуто за ущи звучит. Тем более что ESE и их SQL серверу вроде примерно одинаково лет, плюс-минус лапоть. Просто MS на заре своего развития умудрился набрать вменяемых спецов а не придурков с горящими глазами, лихо забивающих любимом микроскопом гвозди любого калибра. Поэтому с тех времен у них остался ряд достаточно продуманных решений, сделанных специалистами, с задействованием головы. Поэтому кроме всего прочего все это хозяйство работает с достаточно приличной скоростью на достаточно больших объемах данных, что актуально ынтырпрайзникам с AD о десятках миллионов объектов и многими гигазами почты. И даже с учетом безбашенного управления они еще все-таки не все полимеры проср@ли. Вот конкретно эти 2 до сих пор без лобовой замены пока. При желании заменить можно, но возни - будет. И не факт что будет работать так же хорошо. Одна из причин почему MS еще не послали во всех энтерпрайзах, несмотря на геморные условия лицензирования. > А насчет SQL - он у них даже в WMI представлен весьма себе неплохо - где он имхо > совершенно не нyжен. Вот про это - ничего не знаю. Я расписывался лишь за то о чем более-менее в курсе. > Да и работает он... как внешний индексатор... Многие функцию "поддержки поиска" тупо > отключают сразу после инсталла, потому что именно так и реализован. Неа, отключают просто потому что нафиг не упало - те у кого есть мозг обычно и так знают что у них и где лежит. Зачем мне индексатор, если я и так структурую хранение информации и могу быстро найти ее сам? А индексатор по любому будет жрать ресурсы - он по любому должен файлы парсить. Чудес не бывает.
	Ответить | Правка | ^ к родителю #343 | Наверх | Cообщить модератору

	111. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 06:08
	redis embedded решает
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	112. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 06:09
	> redis embedded решает http://www.project-voldemort.com/voldemort/
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	304. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:33
	Чемпионат по громким баззвордам объявляется открытым. Давайте еще какую-нить nosql фигню на яве притащим? :)
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	314. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 16:58
	Visual Basic 6 nosql
	Ответить | Правка | ^ к родителю #304 | Наверх | Cообщить модератору

	326. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:45
	> Visual Basic 6 nosql VB старье. Так что хиленькая попытка, увы :). Сейчас в моде питон. Ну или там руби. Или какой там еще брейнфак с VB-подобным синтаксисом я забыл?
	Ответить | Правка | ^ к родителю #314 | Наверх | Cообщить модератору

34. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
Сообщение от vitalif on 07-Июл-13, 17:33
Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB :DD Кал ведь ещё тот...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	108. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 01:56
	> переход на agpl3 вами, последовательными "сторонниками свободного по", должен быть одобрен Вот это и был бы условный рефлекс на недостаточную информацию.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	110. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 02:19
	Ну вот, теперь мой комментарий без развёртывания выглядит как ответ на его брата.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	139. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–2 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 14:09
	> Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB > :DD > Кал ведь ещё тот... очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили) может выполняться в kernel space.. + в качестве примеров идет чуть ли не кусок журналируемой файлухи.. - очень не плохой вариант.. Вы видимо готовить его не умеете?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	147. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:33
	> очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили) > может выполняться в kernel space.. + в качестве примеров идет чуть > ли не кусок журналируемой файлухи.. - очень не плохой вариант.. Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут, так даже интереснее.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	160. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:01
	> Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут, > так даже интереснее. Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные апи. И документировано неплохо.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	162. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:09
	Для типового проекта на ее базе 99% функционала просто не нужно.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	193. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:35
	> Для типового проекта на ее базе 99% функционала просто не нужно. В любом случае, базы данных, даже простые - относительно навороченный и сложный кусок знаний, который типичному прикладнику вгружать в свою голову совершенно не с руки.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	197. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 17:55
	> В любом случае, базы данных, даже простые - относительно навороченный и сложный > кусок знаний, который типичному прикладнику вгружать в свою голову совершенно не > с руки. Типичный прикладник BDB за пять километров стороной обходит. И правильно делает, кстати.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	292. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 13:57
	> Типичный прикладник BDB за пять километров стороной обходит. И правильно делает, кстати. Вот только я с этой базой именно на примере нужной мне прикладухи и познакомился. Там вылезли грабли, и по этому поводу меня ждала целая экскурсия в мир BDB и даже ее внутренностей немного. В целом увиденное понравилось. Хорошо написана дока, понятно как юзать. Фич прилично. Все логично сделано. Да, а самое приятное - разработчики из sleepycat помогли умахать грабли (оказавшиеся платформо-специфичными) - буквально не более 2 дней на переписку и пришло понимание места где рукоятка грабель внезапно встречается со лбом. При том ни цента за такой годный саппорт не запросили + запатчили грабли в апстриме и выкатили новую версию довольно оперативно. Не знаю, насколько они испортились после покупки ораклем, но до этого с ними и их базой было вполне приятно иметь дело. Из того что НЕ понравилось: оно довольно большое и фич там на порядок больше чем обычно надо от key-value, добавляет довольно много кода. Потом они даже SQL сделали. И скорость работы не чемпионская в своем классе.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	208. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 08-Июл-13, 19:45
	> Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная > и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные > апи. И документировано неплохо. я уже как-то даже подустал: LMDB: http://symas.com/mdb/
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	214. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 21:30
	> я уже как-то даже подустал Милорд, в этом обсуждении нужно больше ссылок на LMDB.
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	222. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 08-Июл-13, 22:01
	> Милорд, в этом обсуждении нужно больше ссылок на LMDB. нужно. потому что куча народу о ней не в курсе. и не все подписаны на обновления, так что некоторые анонимусы, которым оно будет интересно, могут и пропустить.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	294. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:01
	> нужно. потому что куча народу о ней не в курсе. Mmaped -> must die. Нафиг надо kv-базу с лимитом на 4Гб. Шутка юмора не понята.
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	300. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 14:13
	> Mmaped -> must die. Нафиг надо kv-базу с лимитом на 4Гб. Шутка > юмора не понята. см. выше. впрочем, я готов побиться об заклад, что ты не только не понимаешь места и способы применимости k/v, но и никогда не работал с реально большими объёмами данных. поэтому твое мнение — из разряда «я админ локалхоста, я точно знаю, как надо админить парк из 9e+3 машин!»
	Ответить | Правка | ^ к родителю #294 | Наверх | Cообщить модератору

	302. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:23
	> впрочем, я готов побиться об заклад, что ты не только не понимаешь > места и способы применимости k/v, Какой высокопарный апломб. Иди расскажи разработчикам файловых систем с верхним лимитом на экзабайты какие они лохи :). А то они тоже что-то маппят путь к файлу в данные файла. По сути подвид K/V вполне себе. Хоть и оптимизированный под специфичное применение. Ну ты сам нарывался своими generic заявами за "k/v вообще" чтобы тебя так боднули. Ты и сам такие подъ...ки любишь вроде. А тут моя очередь :P. Как раз k/v прекрасны в том числе и 1) Низким оверхедом. 2) Высокой скоростью даже при диком количестве записей. У хэш-таблиц например вообще время работы - O(1). Замечательная штука чтобы туда вагон записей сгрузить.
	Ответить | Правка | ^ к родителю #300 | Наверх | Cообщить модератору

	334. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 00:02
	> Как раз k/v прекрасны в том числе и > 1) Низким оверхедом. > 2) Высокой скоростью даже при диком количестве записей. Именно. И это нужно там, где это нужно. В остальных случаях за использование KV придётся платить изобретанием велосипедов и колёс. К сожалению, очень часто KV юзают там, где не стоило бы.
	Ответить | Правка | ^ к родителю #302 | Наверх | Cообщить модератору

	341. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 02:47
	> Именно. И это нужно там, где это нужно. Вообще случаев где key/value хватит - довольно много. Если не заморачиваться искусственным переусложнением сущностей. > В остальных случаях за использование KV придётся платить изобретанием > велосипедов и колёс. Вот только в насоветованных вами решениях изобретение великов типа экранирования и прочая - вообще сразу подразумевалось по дефолту для ВСЕХ случаев. > К сожалению, очень часто KV юзают там, где не стоило бы. SQL не менее часто юзают где он нафиг не упал. А еще - именно грамотно им пользоваться умеет очень мало народа. Поэтому тут вам и вагон скуль-иньекций в каждой дырке, и адские тормоза казалось бы простых как топор операций, и дикие прелести жизни. Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами. Они там 126 столбцов завели. И хранили, итить, цвет шрифта как отдельную колонку в таблице. В k/v они бы по крайней мере за...сь так извращаться и поневоле пришли бы к более разумным решениям :). Ах да, при чем тут sql.ru? Мускул при попытке создать ЭТО - сдуревал и выдавал ошибку, разумеется :)
	Ответить | Правка | ^ к родителю #334 | Наверх | Cообщить модератору

	344. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 07:23
	> Вот только в насоветованных вами решениях изобретение великов типа экранирования и прочая > - вообще сразу подразумевалось по дефолту для ВСЕХ случаев. Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный код при правильной его организации. Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано), то скорее всего все запросы изначально будут в виде prepared statements, и никакого явного экранирования не потребуют. > Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами. В .ru вообще много примеров использования разных вещей безмозглыми существами... но это ни о чем не говорит.
	Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

	345. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 11:59
	> Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный > код при правильной его организации. Тем не менее, это дополнительные действия. Если данных много, их экранирование/деэкранирование может занять вполне заметное время. Хороший k/v вообще хранит любые данные. Что означает отсутствие таких проблем by design. Намного лучше когда дизайн failsafe сам по себе, да еще и скорость не просядет лишний раз. > Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано), С таким же успехом можно говорить и о обратном переходе там где SQL запихнули "потому что модный buzzword же". И тут вдруг ВНЕЗАПНО до некоторых стало доходить что NoSQL может быть инересной опцией в плане скорости :). В основном потому что там геморно делать неоптимальные запросы. > то скорее всего все запросы изначально будут в виде prepared statements, и > никакого явного экранирования не потребуют. Не, куча допущений - это здорово, конечно, но я не вижу - что даст такой маневр в общем случае кроме лишнего головняка и тормозов. SQL достаточно сложный ЯП, грамотно делать запросы на оном умеет очень небольшое количество народа. А чтобы оно еще и работало со скоростью хоть немного похожей на оную у key-value баз - это вообще рокетсайнс. Я конечно понимаю рвение везде пихать SQL, но обычно как раз это приводит к тому что его пытаются сосватать даже туда где он нафиг не упал. А потом начинаются удивления - "ой, как это - файрфокс начинает тормозить если вы много сайтов посетили?!". И догадайтесь, блин, во что оно уперлось. В сиквельную базу, итить. Во как. >> Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами. > В .ru вообще много примеров использования разных вещей безмозглыми существами... но это > ни о чем не говорит. Хорошо, я могу и иной пример. А вот в амарок2 активно сватали мускуль. Я например совершенно не понял зачем мне в системе здоровенный демон от навороченной базы и просто снес все это безобразие нафиг. Они бы еще пэхэпэ и апач приволокли, блин.
	Ответить | Правка | ^ к родителю #344 | Наверх | Cообщить модератору

	256. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от бедный буратино (ok) on 09-Июл-13, 10:18
	>> Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная >> и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные >> апи. И документировано неплохо. > я уже как-то даже подустал: LMDB: http://symas.com/mdb/ О, любопытно. Токийско-киотские кабинеты мне чем-то не понравились, уже даже не помню чем, давно было. А это вроде милое. Не такое милое, как питоновская shelve с её подложками, но всё равно милое. :)
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	288. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 13:38
	это замена для сишников сотоварищи. нам бидон как-то не в тему будет. собственно, замена именно BDB, потому что у них очень похожие API. а так — ещё hamsterdb есть, например. гуглевый leveldb. tdb из самбы на крайний случай. сотни их.
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	293. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 13:58
	> собственно, замена именно BDB, потому что у них очень похожие API. Только bdb насколко я помню адресным пространством не лимитирована. А для 32-битных платформ лимит в 4Gb может больно шибануть ручкой грабель в лою.
	Ответить | Правка | ^ к родителю #288 | Наверх | Cообщить модератору

	295. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 14:02
	>> собственно, замена именно BDB, потому что у них очень похожие API. > Только bdb насколко я помню адресным пространством не лимитирована. А для 32-битных > платформ лимит в 4Gb может больно шибануть ручкой грабель в лою. если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то делаешь очень неправильно.
	Ответить | Правка | ^ к родителю #293 | Наверх | Cообщить модератору

	301. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:14
	> если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то > делаешь очень неправильно. Жду когда ты себе диск протрешь нулями, а то файловая система тоже маппит ключ "путь и имя файла" в значение "данные файла" :)
	Ответить | Правка | ^ к родителю #295 | Наверх | Cообщить модератору

	331. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 23:57
	> если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то > делаешь очень неправильно. +100500000000000000000000000000000000000000000000000000000000000000000000
	Ответить | Правка | ^ к родителю #295 | Наверх | Cообщить модератору

	346. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 12:02
	> +100500000000000000000000000000000000000000000000000000000000000000000000 А ты уже заменил файловую систему на сиквельную базу? А то микрософтушка что-то вон ниасилил :)
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	173. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:25
	>> очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили) >> может выполняться в kernel space.. + в качестве примеров идет чуть >> ли не кусок журналируемой файлухи.. - очень не плохой вариант.. > Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут, > так даже интереснее. а в чем проблема - они разнесли 2 уровня абстракции - контейнер с транзакциями и журналом и таблицы в этом контейнере. Теперь можно делать что угодно - к слову файловая система (ее часть относящаяся к метаданным) это просто таблицы key->value. Да и данные по сути это дерево которое где-то хранить надо..
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	156. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:57
	> Кал ведь ещё тот... Не согласен. Вполне позитивная либа с позитивными разработчиками. Имел счастье когда-то взаимодействовать с ними, понравилось. Sleepycat был вполне прикольной компанией с весьма приятным народцем. И апи у либы довольно мощное и логичное.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

50. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от umbr (ok) on 07-Июл-13, 19:12
"Умненький Буратино!" (с) Нередко проще купить лицензию чем готовить код к публикации, ибо "как есть" публиковать просто стыдно ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

51. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
Сообщение от Аноним (??) on 07-Июл-13, 19:17
Отличная новость - даже не ожидал от оракла подобного. Давно пора заставлять народ в массовом порядке переходить на последний версии свободных лицензий. А то, понимаешь, развелось тут халявщиков :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от klalafuda on 07-Июл-13, 19:53
	А вот и обделенные судьбою девелуперы подтянулися.. Ты с какого гита будещь? Комиты есть? А если найду?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	119. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 10:00
	> Комиты есть? А если найду? Ой, найди! "Аноним, 19:17 , 07-Июл-13", да?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

52. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
Сообщение от Аноним (??) on 07-Июл-13, 19:18
такую же штуку провернула Canonical со своей Ubuntu Phone. Друзьям - пермиссивная лицензия, всем остальным - GPLv3 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	76. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
	Сообщение от Аноним (??) on 07-Июл-13, 22:38
	> такую же штуку провернула Canonical со своей Ubuntu Phone. Друзьям - пермиссивная > лицензия, всем остальным - GPLv3 :) Как тонко подметил Мэтью Гаррет, из-за Canonical CLA эта конторка может единолично поменять лицензию на все свои пoделия в любой момент. Поэтому убунтофон должен вызывать закономерное недоверие. А вот с ядром, например, такой фокус не прокатит - там CLA нет, и нужно согласие всех авторов.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

115. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+1 +/–
Сообщение от edwin (??) on 08-Июл-13, 08:48
Звонок в целом тревожный ... в ОЧЕНЬ многих продуктах используется BDB. И OpenLDAP и Subversion и Spamassassin и т.д.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	126. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 10:49
	На SQLite перейдут ...
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	141. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от 333 on 08-Июл-13, 15:18
	LDAP???
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	158. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:59
	> LDAP??? Лдап? С скулайтом? Бобби Тэйблс быстро вам объяснит что вы не правы :)
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	210. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от 333 on 08-Июл-13, 21:02
	http://pro-ldap.ru/tr/admin24/intro.html#LDAP vs RDBMS ldap vs sql - вещи плохо совместимые. вместо bdb можно разве что какую-нибдь NoSQL с бинарными деревьями.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	211. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от AlexAT (ok) on 08-Июл-13, 21:11
	NoSQL+BTREE? Тогда уж SQL/BTree - классику, ибо снявши голову...
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	296. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:02
	> NoSQL+BTREE? Тогда уж SQL/BTree - классику, ибо снявши голову... А зачем работать с b-деревом через такую жо... ой, то-есть, бутылочное горлышко SQL?
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	332. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	–1 +/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 23:59
	> А зачем работать с b-деревом через такую жо... ой, то-есть, бутылочное горлышко > SQL? Да я не спорю, можно и с сотней гектаров земли лопатой поработать... но проще взять трактор. А там, где сотни гектаров нет - и разницы не будет, в общем. Есть трактор - хорошо. Нет - тоже хорошо.
	Ответить | Правка | ^ к родителю #296 | Наверх | Cообщить модератору

	347. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 12:15
	> Да я не спорю, можно и с сотней гектаров земли лопатой поработать... Сам по себе kay-value может прекрасно работать с любым объемом данных. Хоть с терабайтом. Доказано файловыми системами :). В случае b-дерева скорость O(log(n)), а в хэш-таблицах вообще O(1). Во втором варианте размер вообще не роялит - вытаскивание записи не зависит от размера базы. > но проще взять трактор. Если посмотреть на нашего любимого враженьку (у конкурентов надо учиться хорошему) - майкрософтушка при наличии у них в портфолио сиквель сервера который они впаривают при каждом удобном случае, тем не менее допер поюзать для активной директории и эксченжа совершенно другой тип стоража - ESE storage engine. Некую хрень с куда более простым доступом но зато куда более быструю. И таки нормальное инженерное решение им воздалось - у всех остальных и по сей день большие проблемы с эквивалентной заменой что AD что Exchange. > А там, где сотни гектаров нет - и разницы не будет, в > общем. Есть трактор - хорошо. Нет - тоже хорошо. Буллшит. Вон майкрософт для кучи гектаров в энтерпрайзе как раз подогнал специализированное двигло где никаким SQL и не пахло, как минмум изначально.
	Ответить | Правка | ^ к родителю #332 | Наверх | Cообщить модератору

	353. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 10-Июл-13, 16:13
	> В случае b-дерева скорость O(log(n)), а в хэш-таблицах вообще O(1). Во втором > варианте размер вообще не роялит — вытаскивание записи не зависит от > размера базы. зависит, естественно. как минимум потому, что O(1) — это только в идеале. и база не в астрале хранится.
	Ответить | Правка | ^ к родителю #347 | Наверх | Cообщить модератору

	359. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 11-Июл-13, 18:39
	> зависит, естественно. как минимум потому, что O(1) — это только в идеале. > и база не в астрале хранится. Тем не менее, если библа обещает 2 дисковые операции - они так и будут 2 дисковыми операциями. Иррелевантно к объему файла. Насколько там ФС окочурится и прочая - вообще оффтопик, ибо проблемы ФС - ну вообще никак не вина БД :) Тем не менее, сами по себе ФС вон масштабируются на терабайты - и ничего, работает. Нормально вполне вроде.
	Ответить | Правка | ^ к родителю #353 | Наверх | Cообщить модератору

	357. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."	+/–
	Сообщение от GG (ok) on 10-Июл-13, 22:54
	> Звонок в целом тревожный ... в ОЧЕНЬ многих продуктах используется BDB. > И OpenLDAP и Subversion и Spamassassin и т.д. Голактеко Опасносте! Придётся перестать жопить код!
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

120. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–4 +/–
Сообщение от Аноним (??) on 08-Июл-13, 10:03
от ГПЛ одни только проблемы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	121. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 10:19
	> от ГПЛ одни только проблемы. _AGPLv3+_ и Оракл решают!
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	356. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от GG (ok) on 10-Июл-13, 22:53
	+_и
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	130. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 13:08
	> от ГПЛ одни только проблемы. Проприетарщикам проблемы - юзерам хорошо :)
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	138. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–1 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 14:07
	>> от ГПЛ одни только проблемы. > Проприетарщикам проблемы - юзерам хорошо :) пока что проблемы начались у debian...
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	144. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:27
	> пока что проблемы начались у debian... Этим уродам проблемы - людям тоже хорошо. Авось вообще вымрут уроды - тогда мир станет немного чище.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	174. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–1 +/–
	Сообщение от linux must __RIP__ on 08-Июл-13, 16:26
	>> пока что проблемы начались у debian... > Этим уродам проблемы - людям тоже хорошо. > Авось вообще вымрут уроды - тогда мир станет немного чище. это вы так о debian ?
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	177. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 16:33
	> это вы так о debian ? Конечно. О ком же еще.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	185. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 08-Июл-13, 16:44
	> пока что проблемы начались у debian... Нет. Не начались. Не веришь? Перечитай ещё раз. Обсуждают только. Это не считается а Debian-е проблемой. ///как и на опеннете
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

132. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
Сообщение от Аноним (??) on 08-Июл-13, 13:12
Что-то оракул в последнее время с лицензиями мутит. Что-то затевает нечистый. То мускуль, то еще что.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	135. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от makky (ok) on 08-Июл-13, 13:41
	Мучу, мучу, верчу - долларов побольше хочу...
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	274. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 12:25
	> Мучу, мучу, верчу - долларов побольше хочу... Верно, чувак. Ораклу кекать на ваши телодвижения. У него цель. Номер один. Кстати, абсолютно верная.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

152. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–2 +/–
Сообщение от northbear (??) on 08-Июл-13, 15:46
Лишний повод для перехода на более актуальную встраиваемую базу c более вменяемой лицензией. В зависимости от применения: либо sqlite, либо какой-нибудь redis. Альтернатив полно... Вносить существенные изменения в BerkeleyDB бессмысленно, там за десятки лет всё вылизано, как яйца кота (пардон, за натурализм).  В рамках своей идеологии BDB уже давно достигла потолка развития...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	157. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 08-Июл-13, 15:58
	> лицензией. В зависимости от применения: либо sqlite, либо какой-нибудь redis. При том ни тот ни другой на прямую замену BDB вообще не але. А переписывать полпрограммы - во счастья то. Впрочем, проприетарщикам так и надо, а остальные думается вопрос утрясут :)
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	230. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–1 +/–
	Сообщение от northbear (??) on 09-Июл-13, 02:17
	BerkeleyDB, пол-программы переписывать? 0_о Вы похоже думаете, что это что-то типа MySQL, да? Если вам для того, чтобы сменить berkeleydb на тот же sqlite, надо переписать пол-программы, то у вас руки не с того места растут и вас к компьютерам подпускать нельзя.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	232. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 02:26
	> BerkeleyDB, пол-программы переписывать? а что такого? вот берём — и используем API без очередного дурацкого слоя обёртки. да-да-да, я знаю, МегаПрограммисты не останавливаются, пока не напишут 13 обёрток над любым апи (а потом добавят ещё несколько — на всякий случай).
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	237. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от northbear (??) on 09-Июл-13, 02:47
	> а что такого? вот берём — и используем API без очередного дурацкого > слоя обёртки. :facepalm: Дай угадаю... лабы по программированию на три балла, не больше, да?
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	238. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 02:53
	> :facepalm: Дай угадаю... лабы по программированию на три балла, не больше, да? ну, я же не настоящий сварщик, я не считаю, что все проблемы можно решить, добавив ещё один слой Очень Полезной Абстракции.
	Ответить | Правка | ^ к родителю #237 | Наверх | Cообщить модератору

	245. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 03:16
	> ну, я же не настоящий сварщик, я не считаю, что все проблемы > можно решить, добавив ещё один слой Очень Полезной Абстракции. Да туфта все эти абстракции. Народу нужны нормальные юниксовые костыли! Вместо уровней API - скрипт, который формирует окружение и запускает скрипт, который пишет и запускает скрипт, который, в свою очередь, дергает кучу других скриптов. Вот это - ок.
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

	247. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 03:18
	что характерно — очень часто это действительно вполне нормальное решение. но у вантузоидов от программ, которые на выходе дают другие программы, обостряется чувство собственной неполноценности.
	Ответить | Правка | ^ к родителю #245 | Наверх | Cообщить модератору

	249. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 03:29
	> что характерно — очень часто это действительно вполне нормальное решение. но у > вантузоидов от программ, которые на выходе дают другие программы, обостряется чувство > собственной неполноценности. Ога. Особенно клево, когда оно записывает туда тексты, пропущенные через пятистрочные регекспы, а потом запускают с рутовыми правами. Не один SQL инъекциями богат...
	Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

	251. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 03:33
	что, бедняша, локалхост так навернул? оно завсегда если мозгов нет — то падает.
	Ответить | Правка | ^ к родителю #249 | Наверх | Cообщить модератору

	327. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 20:50
	> что, бедняша, локалхост так навернул? оно завсегда если мозгов нет — то падает. Не, ну вообще-то у него есть пойнт. Я таким манером пару раз весьма изящно дурачил скрипты автоматического процессинга данных, как ты понимаешь, далеко не все в курсе про Бобби Тэйблса и его коллег по цеху :)
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	328. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 09-Июл-13, 21:57
	ну так специально можно и МПХ сломать, лишь бы цель такая стояла.
	Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

	329. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 22:46
	> ну так специально можно и МПХ сломать, лишь бы цель такая стояла. У скуля как раз неприятная особенность в том что он слишком много всего умеет by default. С другой стороны, нормальной k/v базе совершенно все-равно что получить на вход и что будет данными. Это избавляет от массы головняка.
	Ответить | Правка | ^ к родителю #328 | Наверх | Cообщить модератору

	336. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 00:15
	Прелесть кв не в блобятине - на блобятину можно и скуль заточить (уже ж говорил - prepared statement, и никаких проблем). Прелесть в сравнительно шустром доступе к данным по ключу. С другой стороны, скуль и KV тихонько сливаются в экстазе - вон, NDB или TokuDB (TokuMX, если хотите NoSQL), и разница между ними становится в один парсер. Да и для InnoDB NoSQL access уже запилили. С inmemory тот же Inno/Toku не сравнить, конечно, но мы и не о inmemory говорим. А NDB неплохо так масштабируется, но он явно не эмбеддед :) Имхо будущее за гибридными движками хранилищ, к которым можно обратиться и так и сяк, в зависимости от потребности.
	Ответить | Правка | ^ к родителю #329 | Наверх | Cообщить модератору

	348. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 12:47
	> Прелесть кв не в блобятине - на блобятину можно и скуль заточить Прелесть - в том что 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 тормозные запросы как раз правило а не исключение :) > Имхо будущее за гибридными движками хранилищ, к которым можно обратиться и так > и сяк, в зависимости от потребности. Ну а вот это было бы логично - разделить на "парсер" и "движок". При этом можно было бы менять что парсер на какой-то кастомный, проблемо-ориентированный при нужде, так и движок, на тот который лучше подходит по свойствам. Ну так, в идеале.
	Ответить | Правка | ^ к родителю #336 | Наверх | Cообщить модератору

	354. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+1 +/–
	Сообщение от arisu (ok) on 10-Июл-13, 16:15
	> А в скуле он даже и не узнает > о том что его select * from немеряная_таблица — это плохо. это не программер, это быдлокодер. быдлокодер что угодно испортит.
	Ответить | Правка | ^ к родителю #348 | Наверх | Cообщить модератору

	360. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от Аноним (??) on 11-Июл-13, 18:44
	> это не программер, это быдлoкодер. быдлoкодер что угодно испортит. Нормальный спец по скулю, который реально понимает что реально будет сделано в ответ на тот или иной запрос - весьма редкий вид. Это крутые специалисты получающие вагон денег. На всех их заведомом не хватит и у всех не хватит денег на оплату таких гуру. Поэтому SQLное добрецо обречено создавать окружающим характерные грабли. Если рассмотреть весь процесс в целом.
	Ответить | Правка | ^ к родителю #354 | Наверх | Cообщить модератору

	362. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 11-Июл-13, 21:20
	ой, как будто на k/v не делают таких ужасов, когда смотришь и офигеваешь.
	Ответить | Правка | ^ к родителю #360 | Наверх | Cообщить модератору

	254. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от AlexAT (ok) on 09-Июл-13, 07:30
	Да даже тот же MySQL Embedded можно встроить без особых проблем. Вопрос только в том, что весить оно будет бугага сколько...
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	298. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:06
	> Да даже тот же MySQL Embedded можно встроить Но лучше ты его себе куда-нибудь встрой. Ибо сдавать экзамен на пилотирование боинга при том что я всего-то на скутере хотел погонять - как-то больно недружественно ко мне получается.
	Ответить | Правка | ^ к родителю #254 | Наверх | Cообщить модератору

	333. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 00:00
	А, ну так и скажите - порог вхождения не все осиляют. Это да, факт. Другое дело, когда места посадить боинг / поставить хаммер нет - вот там скутер оправдан. Но в приличном ряде случаев монопенисуально. PS. Не об IT: на скутеры тоже права вводят. К чему бы это? Отсутствие порога вхождения провоцирует поведение на дорогах? :)
	Ответить | Правка | ^ к родителю #298 | Наверх | Cообщить модератору

	349. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 13:13
	> А, ну так и скажите - порог вхождения не все осиляют. Это да, факт. Более того - по этому поводу большинство запросов на скуле - дикий ужас. Подавляющее большинство програмеров вообще не понимают во что их запрос будет трансформирован и в результате - пока у них тестовый сервер о 10 записях в базе - все работает. А вот потом становится очень интересно. В kv базах они начинают замечать промахи в своих подходах очень быстро, т.к. двигло не прячет от прогремера свои проблемы в этом случае. А вот сиквель позволяет сильно нагрузить базу даже не узнав об этом вот так сразу. И да, заиметь это сакральное знание осиливает уже далеко не каждый первый кто запросы на сиквеле фигачит. Может ли сиквель быть не слишком тормозным? Может. Если найти специалиста по ракетным наукам, который собаку на этом съел. Проблема только в том что такие спецы - редки как пингвины в пустыне Сахара и стоят совершенно диких денег. Поэтому их обычно не оказывается в нужном месте в нужное время. Результат достаточно плачевен. > Другое дело, когда места посадить боинг / поставить хаммер нет - вот > там скутер оправдан. Но в приличном ряде случаев монопенисуально. Дело даже не в том - скутер хорошо маневрирует и прост в управлении. А в указанном случае там еще и персональный ракетоплан до кучи встроен - при нужде такой скутер и в стратосферу без зазрения совести сгоняет, если ездок к этому готов. > PS. Не об IT: на скутеры тоже права вводят. К чему бы > это? Отсутствие порога вхождения провоцирует поведение на дорогах? :) Ну как бы да, глупое применение k/v тоже возможно. Но в современном мире намного больше глупых применений SQL, так что как видишь, скутерам в последнюю очередь достается - они далеко не основной источник проблем на дорогах :P.
	Ответить | Правка | ^ к родителю #333 | Наверх | Cообщить модератору

	352. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от AlexAT (ok) on 10-Июл-13, 14:22
	> Ну как бы да, глупое применение k/v тоже возможно. Но в современном > мире намного больше глупых применений SQL, так что как видишь, скутерам > в последнюю очередь достается - они далеко не основной источник проблем > на дорогах :P. Автомобилей тоже больше, чем скутеров...
	Ответить | Правка | ^ к родителю #349 | Наверх | Cообщить модератору

	361. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 11-Июл-13, 18:45
	> Автомобилей тоже больше, чем скутеров... А автомобиль по управлениию ближе к скутеру чем к боингу. Ы?
	Ответить | Правка | ^ к родителю #352 | Наверх | Cообщить модератору

	297. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–1 +/–
	Сообщение от Аноним (??) on 09-Июл-13, 14:05
	> BerkeleyDB, пол-программы переписывать? 0_о Вы похоже думаете, Я не "думаю", я видел эту либу лично и даже в ее кишках немного копался по технической необходимости. Это мощная либа с рядом фич, прямых аналогов которых у остальных нет. Я охотно посмотрю как вы перепишете их апи курсоров например. А оно у "конкурентов" есть? И именно такое же? Даааа?
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	358. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от northbear (??) on 11-Июл-13, 00:24
	Ну, раз вы покопались в кишках, то расскажите нам, чем уникальны курсоры в BDB. На sql-платформах быстро переболели модным функциональным поветрием в виде курсоров. В BDB, как видите, оно осталось, за неимением другого механизма доступа к записям у которых ключи совпадают... Если вам реализация api курсоров кажется сложной, почитайте про итераторы.
	Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

315. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
Сообщение от Anonymouz on 09-Июл-13, 17:00
Кстати, lmdb шикарная вещь, по тестам делает berkeley.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	317. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	+/–
	Сообщение от arisu (ok) on 09-Июл-13, 17:21
	> Кстати, lmdb шикарная вещь, по тестам делает berkeley. да и работает, вроде как, весьма стабильно. у меня, правда, не гигабайтные объёмы данных.
	Ответить | Правка | ^ к родителю #315 | Наверх | Cообщить модератору

342. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	–1 +/–
Сообщение от kombat (ok) on 10-Июл-13, 06:05
Лета не получилось. Вот почему анонимные школьники бороздят в просторах интернета.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	350. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
	Сообщение от Аноним (??) on 10-Июл-13, 13:15
	> Лета не получилось. Вот почему анонимные школьники бороздят в просторах интернета. Как мне вас жаль. Sh*t happens.
	Ответить | Правка | ^ к родителю #342 | Наверх | Cообщить модератору

355. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."	+/–
Сообщение от GG (ok) on 10-Июл-13, 22:48
ВНЕЗАПНО! Оракле начали всё правильно делать Но автор букв немного наркоман: >> Особенностью лицензии AGPLv3 является введение дополнительных ограничений Но не ограничений же, требований обеспечения свободы >> связывание с AGPLv3-библиотекой приведёт к распространению лицензии AGPLv3 на все использующие данную библиотеку пакеты Так не надо статично линковать же >> введя требования по открытию кода web-сервисов, использующих Berkeley DB, компания Oracle пытается стимулировать создателей подобных сервисов к покупке коммерческой лицензии. А мне кажется, что оракле пытается стимулировать создателей перестать жопить код. И это очень правильное стремление. Особенно надо начать переставать жопить модифицированный код владельцам sas, построенным на переделанном под себя свободном софте. А то привыкли, что раз оно на сервере крутится, то можно взять и запроприетарить, раз юзерам только html отдаётся. Нехер. >> владельцем имущественных прав на код ШТО О_о?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема