forum.opennet.ru

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

Оглавление

Berkeley DB переведён на лицензию AGPLv3, что привело к проб..., opennews (ok), 07-Июл-13, (0) [смотреть все]

Что за БРЕД , Sabakwaka (ok), 14:01 , 07-Июл-13, (1) –3 //

Новость звучит, вообще-то, так 171 Торговцы перепакованным BDB опасаются необх, Sabakwaka (ok), 17:01 , 07-Июл-13, (32) –2 //

Вообще-то она звучит так Что гораздо мягче вашего вброса ЗыжВ данном случае для , ананим (?), 17:55 , 07-Июл-13, (40) +9

Беркелеевская база От оракла Под AGPLv3 Wtf Оракл решил сказочно потроллить , Аноним (-), 17:52 , 07-Июл-13, (37) //

Хотят в Зал Славы Интернетов, как Ричард , Andrey Mitrofanov (?), 18:04 , 07-Июл-13, (44) +4 //

Тогда организаторы зала славы могут потроллить в ответ - засчитать как годное до, Аноним (-), 19:37 , 07-Июл-13, (53) +2

Да, неприятная ситуация Могут пострадать многие уважаемые проприетарные вендоры, Аноним (-), 14:01 , 07-Июл-13, (2) +12 //

0, Аноним (-), 14:05 , 07-Июл-13, (3) +9 //

Мне кажется, тут стоит вспомнить о sarcasm jpg, BlackRaven86 (ok), 14:52 , 07-Июл-13, (11) +12

ох тыж ёшкин кот, Full inu (?), 14:06 , 07-Июл-13, (5) +2

Вообще-то на опеннете приняты некоторые меры для того чтобы накручивать было не , Аноним (-), 00:40 , 08-Июл-13, (87) +1

Неожиданно Ты осуждаешь меня за мою насмешку Ты РЕАЛЬНО соглашаешься со всеми , Zenitur (ok), 22:12 , 07-Июл-13, (69) –1

Нет Тебя осуждают за то, что ТЫ соглашаешься с этими высказываниями , Аноним (-), 13:28 , 08-Июл-13, (133)

Oracle, конечно, какашка, но AGPL это правильное направление P S Читайте рассы, ip1981 (ok), 14:06 , 07-Июл-13, (4) +8 //

Фигу показал и врагам-проприертариям, и врагам-свободно-софтверщикам Такой оpа, Andrey Mitrofanov (?), 14:15 , 07-Июл-13, (7) +2 //

Кругом враги , Аноним (-), 15:20 , 07-Июл-13, (18) //

Молодящаяся копирастическая - в кольце вагов Да , Andrey Mitrofanov (?), 15:24 , 07-Июл-13, (20)

ахаха митрофанов опять разоблачает не устал еще покровы срывать , 1 (??), 15:29 , 07-Июл-13, (22) –1 //

Сам-то, решил прикрыться, ник фейкнул Терапия помогает - задумался, так держать, Andrey Mitrofanov (?), 15:35 , 07-Июл-13, (23) +5

расслабься, здесь нет тайны - у меня лишь нет желания регаться на лороподобных р, 1 (??), 18:05 , 07-Июл-13, (45) –1

А регаться никто и не заставляет Просто если уж решил стать прославленным дятлом, Аноним (-), 00:41 , 08-Июл-13, (88) +2
Кстати, FAIL Я, -P например, не зарегистрирован на этом ресурсе И да, имя наст, Andrey Mitrofanov (?), 09:53 , 08-Июл-13, (116) +2

ТОРГУЕШЬ agpl софтом или получаешь прибыль от веб-проекта, использующего agpl со, Sabakwaka (ok), 16:55 , 07-Июл-13, (29)
А заодно еще и беркелей с их лицензией потроллили , Аноним (-), 17:54 , 07-Июл-13, (39) +3 //

Как правило, то, что содержит в названии Berkeley, весьма слабо относится к Berk, Аноним (-), 00:44 , 08-Июл-13, (90)

Да не, все проще корпорасы показали лишний раз что вытереть ноги о тех кто мети, Аноним (-), 01:23 , 08-Июл-13, (97) +2

Это вы к тому как относился автор MySQL к коврикам из GPL , linux must __RIP__ (?), 16:14 , 08-Июл-13, (164) –3

Фиговые из GPL коврики - жесткие и кусачие Поэтому тут что-то сделать может толь, Аноним (-), 16:37 , 08-Июл-13, (182)

Точнее, правообладатель Например, если ты участвуешь в проекте под эгидой Canoni, Аноним (-), 16:40 , 08-Июл-13, (184)

А там ковриком сам оракл выступил походу , Аноним (-), 16:48 , 08-Июл-13, (186)

Что-то дорабатывать или улучшать Зачем Лучше сменить лицензию, чтобы создать в, SubGun (ok), 10:32 , 08-Июл-13, (122) –3 //

Когда человек с ником SubGun начинает втирать про доработку и улучшение - это уж, Аноним (-), 13:30 , 08-Июл-13, (134) +1
Я про AGPL вообще, причём для программ, а не библиотек, и вообще аккуратно , ip1981 (ok), 13:51 , 08-Июл-13, (136)

Вот так в один прекрасный день проснешься, наберешь на автомате apt-get update , klalafuda (?), 14:12 , 07-Июл-13, (6) +1 //

Конечный пользователь не распространяющий ПО в бинарном виде никак не может на, Аноним (-), 15:13 , 07-Июл-13, (15) +3 //

AGPL касается и веб-сайтов причём всех его компонентов , и любых других сервисо, бедный буратино (ok), 17:53 , 07-Июл-13, (38) –4

а потому, что ты просто не смог сформулировать свою мысль , Аноним (-), 22:04 , 07-Июл-13, (67) +3

Я так полагаю, что это сугубо теоретически По крайней мере мне пока что не попа, klalafuda (?), 18:19 , 07-Июл-13, (48)

Это вменяемое средство для сохранения данных Вот когда для построения страницы , бедный буратино (ok), 10:48 , 08-Июл-13, (125) –5

Потому что ты уже достал со своим бидоном , Аноним (-), 17:03 , 08-Июл-13, (187) +1
это невменяемый древний капец, который нормальные люди давно заменили на qmdb lm, arisu (ok), 19:29 , 08-Июл-13, (202) +1

Да не, на самом деле нормальная либа вполне Правда навороченная и не особо шуст, Аноним (-), 12:00 , 09-Июл-13, (264) –1

ок, насчёт 171 невменяемый 187 я погорячился, конечно либа как либа но дал, arisu (ok), 13:34 , 09-Июл-13, (284) +1

Просто в апи есть ряд фич, прямые аналоги у конкурентов которым могут отсутств, Аноним (-), 19:39 , 09-Июл-13, (318)

Не будет Старые версии нельзя перелицензировать задним числом, а вот форкнуть п, Аноним (-), 22:02 , 07-Июл-13, (66) +2
Чу дную ересь несёшь Правда-правда Даже если оракль переведет MySQL на AGPL3 G, AlexAT (ok), 23:05 , 07-Июл-13, (84) +1

А теперь посмотри на имя автора того комментария Еще вопросы есть , Аноним (-), 00:47 , 08-Июл-13, (92) +2
Как будто обилие проблем винды заставило всех соскочить на свободные системы Пл, бедный буратино (ok), 10:44 , 08-Июл-13, (123)

А опенсорс вот как-то работает, всем волкам назло И как-то так более разумные с, Аноним (-), 15:23 , 08-Июл-13, (142)

а чем вам последователям столмана не нравится GPL v3 Вы же призываете сразу по, linux must __RIP__ (?), 16:16 , 08-Июл-13, (165) –3

Как раз наиболее радикальные последователи могут радоваться - такое воротило как, Аноним (-), 17:05 , 08-Июл-13, (188)

И каноникал тоже свой убунтофон под GPLv3 Чудеса в решете А секрет просто - они, Аноним (-), 17:58 , 08-Июл-13, (200)

О Как мило Вы ж бессеребренники, с бесплатным и безлимитным свободным временем, Аноним (-), 11:47 , 09-Июл-13, (259) –2

Лично меня вполне устраивают патчи которые чинят имеющиеся на моих конфигурациях, Аноним (-), 12:04 , 09-Июл-13, (267)

Cо здравым смыслом они не особо дружат, так что вполне ожидаемо , Пингвино (ok), 10:06 , 09-Июл-13, (255)

Новые козни Оракли компания Oracle пытается стимулировать создателей подобных, paulus (ok), 14:24 , 07-Июл-13, (8)
Очень некрасиво получается По сути весьма годная свободная лицензия используетс, MrClon (?), 14:40 , 07-Июл-13, (9) +1 //

Та как раз наоборот, всё красиво Зарабатываете деньги - извольте поделиться, раз, Magister (?), 14:51 , 07-Июл-13, (10) +1 //

Только вот свободный софт, который, скажем, GPLv2 - уже несовместим получается , Magister (?), 14:56 , 07-Июл-13, (12) //

несовместим получается мудофил, которого не устраивают условия AGPL, Sabakwaka (ok), 16:57 , 07-Июл-13, (30) –2

Авторов GPLv2 они не устраивают, суда по тому, что эти лицензии несвоместимы , Аноним (-), 00:42 , 08-Июл-13, (89)

Ну так товарищь Столман сознательно их сделал не совместимыми Так в чем пробле, linux must __RIP__ (?), 16:17 , 08-Июл-13, (167) –4

Ага, а еще он ест детей , Аноним (-), 16:32 , 08-Июл-13, (176)
Ну да, а ПДД сделали несовместимым с спортивными автомобилями, запретив гонять, Аноним (-), 17:06 , 08-Июл-13, (189) +1

некоректное сравнение Скорее уж так - вы едите едите на машине с круглыми колес, linux must __RIP__ (?), 22:52 , 08-Июл-13, (225) –1

Требование открытости кода, который ты _распространяешь_ а не используешь для н, Аноним (-), 01:33 , 09-Июл-13, (227) +1

Но уж никак не требование ПДД не гонять - Ближе к квадратным колесам Хотя мож, linux must __RIP__ (?), 11:53 , 09-Июл-13, (261) –1

Не, не так Если тебе не нравится ПДД - вали, создавай другое государство, стано, Аноним (-), 12:06 , 09-Июл-13, (268) +1

взяли 8212 и заменили v2 на v3 что в проекте написано v2 only идиоты должн, arisu (ok), 19:31 , 08-Июл-13, (203) –1

Всё бы правильно, да ведь и на свободном движке можно зарабатывать деньги, совер, Аноним (-), 18:25 , 07-Июл-13, (49) //

Один момент - безопасность Воспользоваться уязвимостью веб-движка гораздо проще,, Аноним (-), 00:54 , 08-Июл-13, (94)

Т е впаривания лоху г вна завернутого в красивый фантик Называя вещи своими им, Аноним (-), 01:38 , 08-Июл-13, (100)

Опенсорсность никак не мешает этому процессу, как показал нам коcмонавт , Аноним (-), 13:11 , 08-Июл-13, (131)

А у кoсмoнавта, btw, вполне нормальная система Не хуже остальных С точки зрени, Аноним (-), 15:36 , 08-Июл-13, (148) +1

Что и требовалось доказать , Аноним (-), 16:07 , 08-Июл-13, (161) +1

От дополнительной полировки дебиан в г вно отнюдь не превратился Как ни странно, Аноним (-), 17:09 , 08-Июл-13, (190)

Был довольно пaршивый дистр кстати из недавнего замечательная идея - при минор, Аноним (-), 17:49 , 08-Июл-13, (194) –1

Дебиан вполне обычен и даже зауряден как дистр, но есть и несколько козырей 1 , Аноним (-), 12:18 , 09-Июл-13, (271)

171 security by obscurity 187 8212 это метод не защиты от уязвимостей, а , arisu (ok), 19:33 , 08-Июл-13, (204) +1

Не только от клиентов Хотя от того же тупого пентестинга сканером, конечно, не з, Аноним (-), 21:32 , 08-Июл-13, (215)

в основном 8212 от клиентов и security reviewers о чём клиент не знает 821, arisu (ok), 21:58 , 08-Июл-13, (220) +1

Свободные лицензии - это MIT, BSD, Apache, Boost GPL же изначально вводились в, klalafuda (?), 15:04 , 07-Июл-13, (13) –8 //

А ваши свободные - для отжатия халявной рабсилы С чем тоже успешно справляютс, Аноним (-), 15:19 , 07-Июл-13, (17) +2 //

Чума на оба ваших дома , Аноним (-), 11:50 , 09-Июл-13, (260)

То ли дело NVidia, VIA, ARM, Juniper, Apple Great Artists Steal Такие м, Andrey Mitrofanov (?), 15:22 , 07-Июл-13, (19) +4 //

Открывающий тег потерял Валидатор не одобряет , Аноним (-), 15:27 , 07-Июл-13, (21) –2

Настоящий парсер ставит нужные теги по контексту сам А вот тyпоботы - палятся, , Аноним (-), 01:39 , 08-Июл-13, (101)

Тест Тьюринга NO CARRIERНеожиданно положительный результат , Andrey Mitrofanov (?), 09:58 , 08-Июл-13, (118)

Оть иманна , Sabakwaka (ok), 16:57 , 07-Июл-13, (31) –3
GPL как раз вводилась в оборот, чтобы всякие умники-коммерсанты не могли отжимат, vitalif (?), 17:36 , 07-Июл-13, (36) +1 //

С хромом плохой пример, например mysql прекрасно бывают и свободная и коммерческ, Гость (?), 23:20 , 07-Июл-13, (85)

Ну дык правообладатель может выдавать кому угодно какие угодно лицензии , Аноним (-), 23:37 , 07-Июл-13, (86) +1
Хм Ну да Но не факт, что гугл бы был эксклюзивным правообладателем вебкита , vitalif (?), 02:09 , 08-Июл-13, (109)

Список проприетарных подстилок не полный MS PL где Как посмотришь на продукцию, Аноним (-), 01:49 , 08-Июл-13, (107) +1 //

ты перепутал - эти лицензии признаны свободными и открытыми , linux must __RIP__ (?), 14:47 , 08-Июл-13, (140) –3

Открыты они прежде всего для проприетарщиков , Аноним (-), 15:28 , 08-Июл-13, (145)
Я не знаю для кого оно там свбодное и открытое, но если я куплю железку от жунип, Аноним (-), 15:40 , 08-Июл-13, (149) +1

Да, эти лицензии свободные Но не для тебя , Аноним (-), 16:13 , 08-Июл-13, (163)
Обещаных кем цитату плиз Я вот вижу как RedHat обещавший всего и много - потихо, linux must __RIP__ (?), 16:20 , 08-Июл-13, (169) –5

Да и в LKML уже патчи не присылают , Аноним (-), 16:35 , 08-Июл-13, (178) –1

Ну да, а какой-нибудь Дэйв Эйрли из редхата в курсах о том какой он там жадный , Аноним (-), 17:14 , 08-Июл-13, (192) +1

Ну так Linux - проприетарное пoделие, это тебе любой линуксмастрип расскажет , Аноним (-), 17:51 , 08-Июл-13, (195)

Да вон вы утверждаете же ты перепутал - эти лицензии признаны свободными и откр, Аноним (-), 17:11 , 08-Июл-13, (191) +1

Хм код который взял кто-то и под себя додел что куда-то пропал вы его взять н, linux must __RIP__ (?), 21:44 , 08-Июл-13, (216) –2

Внезапно, да У сони на PS4 есть игры А на фрибсдах - дырка от бублика И уж ко, Аноним (-), 12:25 , 09-Июл-13, (273) +2

Они также являются свободными для _закрытия_ В отличие от Это коренно-и-отличн, Andrey Mitrofanov (?), 16:22 , 08-Июл-13, (170) +1

Или отдачи в проект Второй вариант не так уж и плох , Аноним (-), 18:02 , 07-Июл-13, (43) +1 //

Вы таки действительно верите в то, что Оракел спит и мечтает, чтобы ему кто-то ч, klalafuda (?), 18:15 , 07-Июл-13, (47) –1 //

Гм, вообще, ситуация когда корпорас отпинывается ногами от желающих поработать н, Аноним (-), 01:41 , 08-Июл-13, (102) +1

Народное правило Скупой платит дважды ещё никто не отменял Оракл - это корпора, klalafuda (?), 11:07 , 08-Июл-13, (127) –1

Вот проприетарщики и ощущают это на своей попе во весь рост, все сильнее и сильн, Аноним (-), 15:42 , 08-Июл-13, (150) –1

Вообще, это ужасно, что BERKELEY DB не под родной лицензией BSD BERKELEY Softwa, Омский линуксоид (ok), 15:10 , 07-Июл-13, (14) //

Вступят в евросоюз , Аноним (-), 20:48 , 07-Июл-13, (57)

несмотря на это, bdb мало где используется по факту и мало где является ключевым, all_glory_to_the_hypnotoad (ok), 15:15 , 07-Июл-13, (16) //

Эээ редко, но метко rpm использует bdb, а это ключевой компонент многих дистр, Stax (ok), 15:40 , 07-Июл-13, (24) –1 //

CODE 15 02 2006 12 42 Компания Oracle купила Sleepycat Software CODE Ай-яй-яй, Andrey Mitrofanov (?), 15:47 , 07-Июл-13, (25) +2
с rpm ом это проблема, но тем не менее не сложно переписать на других аналогах , all_glory_to_the_hypnotoad (ok), 15:56 , 07-Июл-13, (28) +4
Хм Слаководы вполне себе живут без PAMа, потому что им гуру запретил , Аноним (-), 00:49 , 08-Июл-13, (93) //

Да им не привыкать, там вся система - и удобства во дворе , Аноним (-), 01:42 , 08-Июл-13, (103) +6

Удобства не нужны же , Аноним (-), 15:31 , 08-Июл-13, (146)

Только зимой ж па мерзнет, а так ничего , Аноним (-), 15:43 , 08-Июл-13, (151) +3

Потому что ты идиoт А я умный, у меня ничего не мерзнет arisu, Аноним (-), 17:53 , 08-Июл-13, (196)

Ага, можно конечно ставить костыли своему скворечнику и даже буржуйку для отоп, Аноним (-), 12:28 , 09-Июл-13, (275) –1

угу вот я и не занимаюсь борьбой с системой вместо нормального её использования, arisu (ok), 13:52 , 09-Июл-13, (291) +1

Вполне имеющий право на жизнь подход Тебе так удобно - ну и ладушки А мне ваш , Аноним (-), 14:55 , 09-Июл-13, (311) –1

да на здоровье вообще, в слаке штатно есть post-install скрипты, а зависимости , arisu (ok), 15:02 , 09-Июл-13, (313)

Ну дык слаку пользуют обычно олдскульщики, которые удобствами не избалованы Так, Аноним (-), 20:03 , 09-Июл-13, (319)
наоборот как раз удобствами мы очень избалованы а вот от свистелок и перделок , arisu (ok), 20:10 , 09-Июл-13, (320) –1
У вас там довольно специфичное понимание удобств Зато я могу сходить в мой , Аноним (-), 02:15 , 10-Июл-13, (337)

потому что оно нам нафиг не надо но ты, конечно, продолжай рассказывать чушь пр, arisu (ok), 19:40 , 08-Июл-13, (206) +1

Покайсо, и избавит тебя Господь от наказания за грехи твоя Либо терпи, ибо ск, Аноним (-), 19:52 , 08-Июл-13, (209)
Что вам надо, а что нет - решать не вам, а Патрику Ибо воистину , Аноним (-), 21:25 , 08-Июл-13, (212) +2

За кого-то решает Патрик, за кого-то Леннарт, за кого-то Марк Но все, сцуко, как, Аноним (-), 21:27 , 08-Июл-13, (213) –1

Ну так все правильно Линух же не винда или макось где все гвоздями приколочено , Аноним (-), 12:32 , 09-Июл-13, (276)

меня не обещали зверски убить, если я сменю дистрибутив или пересоберу пакеты та, arisu (ok), 22:00 , 08-Июл-13, (221) –1

У тебя в основном нет предпочтений За тебя предпочитают мейнтейнеры слаки , Аноним (-), 01:36 , 09-Июл-13, (228) +1

как у тебя пердак-то жжот , arisu (ok), 01:39 , 09-Июл-13, (229) –1

У меня С чего бы Мои религиозные чувства не были оскорблены да и нельзя их ос, Аноним (-), 02:26 , 09-Июл-13, (233)

а я откуда знаю пердак-то у тебя дымится , arisu (ok), 02:35 , 09-Июл-13, (235)

Фу, как неуклюже Напоминаешь упоpотого бздишника в соседнем треде - над ним уже, Аноним (-), 03:04 , 09-Июл-13, (240)

я же не виноват, что ты дурак , arisu (ok), 03:05 , 09-Июл-13, (242)
То, что мне, дураку, удалось заставить тебя, такого умного, добровольно прыгнуть, Аноним (-), 03:12 , 09-Июл-13, (244)
где я сказал 171 злодей 187 я сказал 171 дурак 187 ты читать, что ли, , arisu (ok), 03:16 , 09-Июл-13, (246)
Вопрос о моем злодействе тебя не касается Это так было, замечание на полях Успо, Аноним (-), 03:25 , 09-Июл-13, (248)
больше заискивающих смайлов давай , arisu (ok), 03:32 , 09-Июл-13, (250)
Арису, ты знаешь, а дураком-то ты выглядишь , Аноним (-), 12:04 , 09-Июл-13, (266)
А вы еще тупее выглядите У arisu хотя-бы аргументы просматриваются А у вас тол, Аноним (-), 12:34 , 09-Июл-13, (277) +1
аргументы у меня есть всегда, просто большинство 171 оппонентов 187 показыва, arisu (ok), 13:36 , 09-Июл-13, (287) +1
мне можно, я и вправду дурак хоть и гений , arisu (ok), 13:34 , 09-Июл-13, (285) +1

LMDB http symas com mdb в частности Since the LMDB API is similar to Berkel, arisu (ok), 19:39 , 08-Июл-13, (205) +1

Вангую взлёт SQLite , AlexAT (ok), 17:09 , 07-Июл-13, (33) //

Так оно уже давно взлетело В браузерах, например , Аноним (-), 00:46 , 08-Июл-13, (91) +1 //

Только слопупочит немилосердно на некоторых операциях без костылей Хотя слоупоч, Аноним (-), 01:44 , 08-Июл-13, (105) //

Да там не из-за SQL слоупочность Там во время записи блокируется весь файл цели, AlexAT (ok), 07:20 , 08-Июл-13, (114)

Сами по себе множественные writer ы - это уже заявка на большой и крутой двигун , Аноним (-), 15:49 , 08-Июл-13, (153)

это же плюсовое дерьмо на шаблонах, 1МБ к бинарю и прочие плюсовые пакости На, all_glory_to_the_hypnotoad (ok), 22:33 , 08-Июл-13, (223) –2

ты попутал tokyo cabinet и kyoto cabinet а ещё qdbm есть , arisu (ok), 23:04 , 08-Июл-13, (226) +2
Вас жестоко глючит, токийский кабинет на голом си написан Это наверное было пр, Аноним (-), 12:40 , 09-Июл-13, (278) +1

Сравнил попу с пальцем А ничего что скулайт не умеет kev-value, в отличие от А, Аноним (-), 01:43 , 08-Июл-13, (104) //

Я в курсе Но из embedded движков логичнее выбрать SQLite, если конечно параллел, AlexAT (ok), 07:19 , 08-Июл-13, (113) //

Не ужели да как они могли А вот когда gcc такую шутку провернул с libgcc - вс, linux must __RIP__ (?), 09:57 , 08-Июл-13, (117) –5

RTFM однако http www gnu org licenses gcc-exception-faq htmlЧто впрочем не уд, klalafuda (?), 10:46 , 08-Июл-13, (124) –1

что удивительно - это exception появился очень не сразу сначала 4 3 был выпущен, linux must __RIP__ (?), 11:36 , 08-Июл-13, (128) –2

Я не в курсе деталей этой истории, но лично мне ничего удивительного в ней не ви, klalafuda (?), 11:44 , 08-Июл-13, (129)

Вот вот Пусть делают свой самый свободный компилятор А то ложечки нашлись - , linux must __RIP__ (?), 14:06 , 08-Июл-13, (137) –1

удаки и идоры потому что Сегодня лишний раз в этом убедился да, и это никак не, Аноним (-), 15:25 , 08-Июл-13, (143)

Конкурентов у GCC практически нет Clang LLVM только-только начал ядро более-м, northbear (??), 15:56 , 08-Июл-13, (155) –1

наверно вы помните - что ядро Clang собирал уже давно Но слишком много програм, linux must __RIP__ (?), 16:22 , 08-Июл-13, (171) –2

Давно это 2-3 года Сравните например с возрастом проекта GNU GCC 1987 год или, northbear (??), 02:25 , 09-Июл-13, (231) –1

Как раз сборка ядра - это совсем не показатель Его можно собирать всем, чем уго, klalafuda (?), 16:29 , 08-Июл-13, (175) –1

Я молча развожу руками Может продемонстрируете , northbear (??), 02:35 , 09-Июл-13, (234) –1

tcc когда-то собирал ядро прямо при загрузке было забавно интересно, способен л, arisu (ok), 02:36 , 09-Июл-13, (236) +1

ТССBOOT собирал адаптированные исходники собранные в ISO-образ ТСС ничего не зн, northbear (??), 03:03 , 09-Июл-13, (239) –1
вообще-то с тех пор tcc значительно подрос и да ядро таки может работать и без, arisu (ok), 03:05 , 09-Июл-13, (241) +1
Ну да, а еще можно руку ампутировать Печатать на клавиатуре и одной рукой можно, Аноним (-), 12:43 , 09-Июл-13, (279) –1
а зачем мне в ядре sse и kvm не 171 зачем оно вообще надо 187 , а 171 зач, arisu (ok), 13:45 , 09-Июл-13, (290) +1
Зачем лично тебе - не знаю, за отсутствием телепатического устройства Лично мне , Аноним (-), 14:41 , 09-Июл-13, (305) –1
вы точно уверены в своих словах AES CRC32 и прочие подобные инструкции - не явл, linux must __RIP__ (?), 17:14 , 09-Июл-13, (316) –1
Я уверен что я в состоянии прочитать dmesg и увидеть где самые забористые бенчи , Аноним (-), 20:21 , 09-Июл-13, (321) –1

Его можно собирать всем, чем угодно с точки зрения лицензии тулчейна и его об, klalafuda (?), 11:16 , 09-Июл-13, (258) –1
icc, open64, tcc, Led (ok), 12:22 , 09-Июл-13, (272)

Спасибо, что спросили Исключение про рантайм там было чуть не с созданья мира, Andrey Mitrofanov (?), 16:36 , 08-Июл-13, (181) +1

вы серьезно верите что поменяв лицензию - народ не задумывался о том что менять , linux must __RIP__ (?), 21:49 , 08-Июл-13, (217) –3

Мартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала , Andrey Mitrofanov (?), 22:49 , 08-Июл-13, (224) +2

а по теме сказать чего-то есть я вижу только веру в великого , linux must __RIP__ (?), 11:54 , 09-Июл-13, (262) –1

Да какая там вера Обычный жирный троллинг всяких глупых личностей Они, кстати,, Аноним (-), 12:45 , 09-Июл-13, (280)

Как по мне я вижу минимум 2 причины НЕ выбирать его 1 SQL априори тормозной и е, Аноним (-), 15:54 , 08-Июл-13, (154)

И в SQL-based KV store тоже - потому что вся обертка делается в - get - set А , AlexAT (ok), 15:59 , 08-Июл-13, (159)

Ты издеваешься или как Можно взять готовое решение которое работает быстро и бе, Аноним (-), 16:17 , 08-Июл-13, (166)

Да нет Мне просто ехать, а не шашечки , AlexAT (ok), 16:20 , 08-Июл-13, (168)

ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB , linux must __RIP__ (?), 16:23 , 08-Июл-13, (172) –1

Вы таки серьезно считаете, что в том же SQLite на бакенде текстовый файл со стро, klalafuda (?), 16:35 , 08-Июл-13, (179)

Нет, там конечно бинарный стораж, но простой и быстрой дорожки его дернуть не да, Аноним (-), 16:37 , 08-Июл-13, (183)

Два слова prepared statements - о чём-нибудь говорят , AlexAT (ok), 17:57 , 08-Июл-13, (199) –1

говорит - что исполнение байт кода - всегда дольше чем просто поиск по базе key-, linux must __RIP__ (?), 21:50 , 08-Июл-13, (218) –3
Если обращения к KV store в inner loop - да, разница будет Но обычно обращения , AlexAT (ok), 07:16 , 09-Июл-13, (252)
Ага Особенно если нужно обработать данные из таблички с парой-тройкой десятков-, klalafuda (?), 11:05 , 09-Июл-13, (257)
не надо издеваться с детей - вот к примеру filldir вполне себе выполняется в, linux must __RIP__ (?), 11:56 , 09-Июл-13, (263) –1
Ну ручки-то они - вона какие , AlexAT (ok), 12:09 , 09-Июл-13, (270)
Вот, лакмусовая бумажка на крап-дезигнеров сработала Если у вас случилась ситуа, AlexAT (ok), 23:55 , 09-Июл-13, (330)
Тем не менее, справедливости ради - сиквельная будет вычитывать записи ничуть не, Аноним (-), 02:24 , 10-Июл-13, (339) +1
Если тебе приходится это делать с K V - ты что-то делаешь не так Совсем не так , Аноним (-), 02:20 , 10-Июл-13, (338) +1
Плохо с произвольным поиском по ключу а индексация там к чему А о словах secon, linux must __RIP__ (?), 12:00 , 09-Июл-13, (265)
Здравый смысл и понимание алгоритмов говорят мне что лукап по b-дереву или хэш-т, Аноним (-), 12:51 , 09-Июл-13, (281)
Ты так и не понял сути Основная проблема - не в том, что нет KV на замену, а в , AlexAT (ok), 14:43 , 09-Июл-13, (306)
Такое наверное бывает, но это можно делать из чувства мазохизма разве что Это с, Аноним (-), 20:33 , 09-Июл-13, (322)

Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того, что раб, AlexAT (ok), 17:56 , 08-Июл-13, (198) +1

у кого как - , linux must __RIP__ (?), 21:50 , 08-Июл-13, (219) –2

Ну, у юнит-тестов BDB все, конечно, иначе , Аноним (-), 03:07 , 09-Июл-13, (243)

А это как бы весьма зависит от Такие базы ставят там где скорость работы с базо, Аноним (-), 12:56 , 09-Июл-13, (282)

Особенно в том же SVN, агаугу Или в PAM Там и SQL нахрен не впёрся, конечно, н, AlexAT (ok), 14:46 , 09-Июл-13, (307) –1

Ой, как они им пользуются - я без понятия Не интересуюсь некромансией В git на, Аноним (-), 20:39 , 09-Июл-13, (323)

Я серьезно считаю, что ты путаешь метод доступа и метод хранения В SQL-based дв, AlexAT (ok), 07:22 , 09-Июл-13, (253)

Замечена попытка ухода в сторону Вами был выдвинут тезис что реализация KV стор, linux must __RIP__ (?), 12:06 , 09-Июл-13, (269) –2
Вот только сперва донавесить парсер, а потом путем длительной борьбы задеградиро, Аноним (-), 13:28 , 09-Июл-13, (283)

В 1 случаев - не заменяет Попытки проехать на велосипеде от Москвы до хотя бы , AlexAT (ok), 14:47 , 09-Июл-13, (308)

Да фигня вопрос Кладем в багажный отсек поезда самолета и едем , Аноним (-), 20:40 , 09-Июл-13, (324)

Мне тоже И мне совершенно не улыбается идея опилить сначала самосвал до легкову, Аноним (-), 16:35 , 08-Июл-13, (180)

Я согласен, что для KV лучше использовать именно KV сторейджи Но в приличном ря, AlexAT (ok), 19:00 , 08-Июл-13, (201) +1

KV обычно применяется тем где надо быстро лопатить много записей в примитивном в, Аноним (-), 13:35 , 09-Июл-13, (286)

При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне пр, AlexAT (ok), 14:48 , 09-Июл-13, (309)

а это называется 171 мы узнали модный баззворд 187 если в задаче часто треб, arisu (ok), 14:56 , 09-Июл-13, (312) +1
Да вы, я так смотрю, эксперт по забиванию гвоздей микроскопом Вы умеете сватать, Аноним (-), 20:43 , 09-Июл-13, (325)

LMDB http symas com mdb , arisu (ok), 19:42 , 08-Июл-13, (207) +1

mmaped - на 32-бит платформах лимитирована 4Гб Это фэйл , Аноним (-), 13:43 , 09-Июл-13, (289) –1

скажи, что у тебя за база размером в терабайты и что за приложение, которое тре, arisu (ok), 14:10 , 09-Июл-13, (299) +1

С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком при, Аноним (-), 14:33 , 09-Июл-13, (303) –1

MS уже пыталась Идея, кстати, неплоха, но опять же - не стоит ее везде лепить -, AlexAT (ok), 00:04 , 10-Июл-13, (335)

Но зафэйлили И если уж на то пошло, у MS есть собственный весьма забористый ESE, Аноним (-), 02:35 , 10-Июл-13, (340)

Имхо просто переделывать некому пока А насчет SQL - он у них даже в WMI предста, AlexAT (ok), 07:20 , 10-Июл-13, (343)

Написать SQL сервак есть кому, написать ESE storage есть кому, а переделать неко, Аноним (-), 14:01 , 10-Июл-13, (351)

redis embedded решает, Аноним (-), 06:08 , 08-Июл-13, (111) //

http www project-voldemort com voldemort , Аноним (-), 06:09 , 08-Июл-13, (112) //

Чемпионат по громким баззвордам объявляется открытым Давайте еще какую-нить nos, Аноним (-), 14:33 , 09-Июл-13, (304)

Visual Basic 6 nosql, Аноним (-), 16:58 , 09-Июл-13, (314)

VB старье Так что хиленькая попытка, увы Сейчас в моде питон Ну или там ру, Аноним (-), 20:45 , 09-Июл-13, (326) +1

Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB DDК, vitalif (?), 17:33 , 07-Июл-13, (34) –1 //

Вот это и был бы условный рефлекс на недостаточную информацию , Аноним (-), 01:56 , 08-Июл-13, (108) //

Ну вот, теперь мой комментарий без развёртывания выглядит как ответ на его брата, Аноним (-), 02:19 , 08-Июл-13, (110)

очень удобная реализация деревьев сторадж с поддержкой транзакций как говор, linux must __RIP__ (?), 14:09 , 08-Июл-13, (139) –2 //

Для любителей делать троллейбусы из буханок хлеба Так они свой велосипед напишу, Аноним (-), 15:33 , 08-Июл-13, (147) //

Велик уровня беркелейской либы придется делать довольно долго Это довольно прод, Аноним (-), 16:01 , 08-Июл-13, (160)

Для типового проекта на ее базе 99 функционала просто не нужно , Аноним (-), 16:09 , 08-Июл-13, (162)

В любом случае, базы данных, даже простые - относительно навороченный и сложный , Аноним (-), 17:35 , 08-Июл-13, (193)

Типичный прикладник BDB за пять километров стороной обходит И правильно делает,, Аноним (-), 17:55 , 08-Июл-13, (197)

Вот только я с этой базой именно на примере нужной мне прикладухи и познакомился, Аноним (-), 13:57 , 09-Июл-13, (292)

я уже как-то даже подустал LMDB http symas com mdb , arisu (ok), 19:45 , 08-Июл-13, (208) +1

Милорд, в этом обсуждении нужно больше ссылок на LMDB , Аноним (-), 21:30 , 08-Июл-13, (214) –1

нужно потому что куча народу о ней не в курсе и не все подписаны на обновления, arisu (ok), 22:01 , 08-Июл-13, (222)

Mmaped - must die Нафиг надо kv-базу с лимитом на 4Гб Шутка юмора не понята , Аноним (-), 14:01 , 09-Июл-13, (294) –1

см выше впрочем, я готов побиться об заклад, что ты не только не понимаешь мест, arisu (ok), 14:13 , 09-Июл-13, (300) +1

Какой высокопарный апломб Иди расскажи разработчикам файловых систем с верхним , Аноним (-), 14:23 , 09-Июл-13, (302) –1

Именно И это нужно там, где это нужно В остальных случаях за использование KV , AlexAT (ok), 00:02 , 10-Июл-13, (334)

Вообще случаев где key value хватит - довольно много Если не заморачиваться иск, Аноним (-), 02:47 , 10-Июл-13, (341)
Да что вы уперлись в это экранирование Экранирование запроса - это минимальный , AlexAT (ok), 07:23 , 10-Июл-13, (344)
Тем не менее, это дополнительные действия Если данных много, их экранирование д, Аноним (-), 11:59 , 10-Июл-13, (345)

О, любопытно Токийско-киотские кабинеты мне чем-то не понравились, уже даже не , бедный буратино (ok), 10:18 , 09-Июл-13, (256) –1

это замена для сишников сотоварищи нам бидон как-то не в тему будет собственно, arisu (ok), 13:38 , 09-Июл-13, (288) +1

Только bdb насколко я помню адресным пространством не лимитирована А для 32-бит, Аноним (-), 13:58 , 09-Июл-13, (293) –1

если у тебя несколькогигабайтная база в k v 8212 ты, мне кажется, что-то дела, arisu (ok), 14:02 , 09-Июл-13, (295)

Жду когда ты себе диск протрешь нулями, а то файловая система тоже маппит ключ , Аноним (-), 14:14 , 09-Июл-13, (301)
100500000000000000000000000000000000000000000000000000000000000000000000, AlexAT (ok), 23:57 , 09-Июл-13, (331) –1

А ты уже заменил файловую систему на сиквельную базу А то микрософтушка что-то , Аноним (-), 12:02 , 10-Июл-13, (346)

а в чем проблема - они разнесли 2 уровня абстракции - контейнер с транзакциями и, linux must __RIP__ (?), 16:25 , 08-Июл-13, (173) –1

Не согласен Вполне позитивная либа с позитивными разработчиками Имел счастье к, Аноним (-), 15:57 , 08-Июл-13, (156)

Умненький Буратино с Нередко проще купить лицензию чем готовить код к публик, umbr (ok), 19:12 , 07-Июл-13, (50)
Отличная новость - даже не ожидал от оракла подобного Давно пора заставлять наро, Аноним (-), 19:17 , 07-Июл-13, (51) +1 //

А вот и обделенные судьбою девелуперы подтянулися Ты с какого гита будещь Ком, klalafuda (?), 19:53 , 07-Июл-13, (54) //

Ой, найди Аноним, 19 17 , 07-Июл-13 , да , Andrey Mitrofanov (?), 10:00 , 08-Июл-13, (119) +2

такую же штуку провернула Canonical со своей Ubuntu Phone Друзьям - пермиссивна, Аноним (-), 19:18 , 07-Июл-13, (52) //

Как тонко подметил Мэтью Гаррет, из-за Canonical CLA эта конторка может единолич, Аноним (-), 22:38 , 07-Июл-13, (76) +1

Звонок в целом тревожный в ОЧЕНЬ многих продуктах используется BDB И OpenLDA, edwin (??), 08:48 , 08-Июл-13, (115) +1 //

На SQLite перейдут , Аноним (-), 10:49 , 08-Июл-13, (126) //

LDAP , 333 (?), 15:18 , 08-Июл-13, (141) //

Лдап С скулайтом Бобби Тэйблс быстро вам объяснит что вы не правы , Аноним (-), 15:59 , 08-Июл-13, (158)

http pro-ldap ru tr admin24 intro html LDAP vs RDBMSldap vs sql - вещи плохо с, 333 (?), 21:02 , 08-Июл-13, (210)

NoSQL BTREE Тогда уж SQL BTree - классику, ибо снявши голову , AlexAT (ok), 21:11 , 08-Июл-13, (211) –1

А зачем работать с b-деревом через такую жо ой, то-есть, бутылочное горлышко , Аноним (-), 14:02 , 09-Июл-13, (296)

Да я не спорю, можно и с сотней гектаров земли лопатой поработать но проще вз, AlexAT (ok), 23:59 , 09-Июл-13, (332) –1

Сам по себе kay-value может прекрасно работать с любым объемом данных Хоть с те, Аноним (-), 12:15 , 10-Июл-13, (347)

зависит, естественно как минимум потому, что O 1 8212 это только в идеале , arisu (ok), 16:13 , 10-Июл-13, (353)

Тем не менее, если библа обещает 2 дисковые операции - они так и будут 2 дисковы, Аноним (-), 18:39 , 11-Июл-13, (359)

Голактеко Опасносте Придётся перестать жопить код , GG (ok), 22:54 , 10-Июл-13, (357)

от ГПЛ одни только проблемы , Аноним (-), 10:03 , 08-Июл-13, (120) –4 //

_AGPLv3 _ и Оракл решают , Andrey Mitrofanov (?), 10:19 , 08-Июл-13, (121) +1 //

_и, GG (ok), 22:53 , 10-Июл-13, (356)

Проприетарщикам проблемы - юзерам хорошо , Аноним (-), 13:08 , 08-Июл-13, (130) //

пока что проблемы начались у debian , linux must __RIP__ (?), 14:07 , 08-Июл-13, (138) –1 //

Этим уродам проблемы - людям тоже хорошо Авось вообще вымрут уроды - тогда мир с, Аноним (-), 15:27 , 08-Июл-13, (144) –1

это вы так о debian , linux must __RIP__ (?), 16:26 , 08-Июл-13, (174) –1

Конечно О ком же еще , Аноним (-), 16:33 , 08-Июл-13, (177)

Нет Не начались Не веришь Перечитай ещё раз Обсуждают только Это не считаетс, Andrey Mitrofanov (?), 16:44 , 08-Июл-13, (185) +1

Что-то оракул в последнее время с лицензиями мутит Что-то затевает нечистый То, Аноним (-), 13:12 , 08-Июл-13, (132) //

Мучу, мучу, верчу - долларов побольше хочу , makky (ok), 13:41 , 08-Июл-13, (135) //

Верно, чувак Ораклу кекать на ваши телодвижения У него цель Номер один Кстат, Аноним (-), 12:25 , 09-Июл-13, (274)

Лишний повод для перехода на более актуальную встраиваемую базу c более вменяемо, northbear (??), 15:46 , 08-Июл-13, (152) –2 //

При том ни тот ни другой на прямую замену BDB вообще не але А переписывать полп, Аноним (-), 15:58 , 08-Июл-13, (157) //

BerkeleyDB, пол-программы переписывать 0_о Вы похоже думаете, что это что-то ти, northbear (??), 02:17 , 09-Июл-13, (230) –1 //

а что такого вот берём 8212 и используем API без очередного дурацкого слоя о, arisu (ok), 02:26 , 09-Июл-13, (232) +1

facepalm Дай угадаю лабы по программированию на три балла, не больше, да , northbear (??), 02:47 , 09-Июл-13, (237)

ну, я же не настоящий сварщик, я не считаю, что все проблемы можно решить, добав, arisu (ok), 02:53 , 09-Июл-13, (238)

Да туфта все эти абстракции Народу нужны нормальные юниксовые костыли Вместо у, Аноним (-), 03:16 , 09-Июл-13, (245) –1

что характерно 8212 очень часто это действительно вполне нормальное решение , arisu (ok), 03:18 , 09-Июл-13, (247) +1

Ога Особенно клево, когда оно записывает туда тексты, пропущенные через пятистр, Аноним (-), 03:29 , 09-Июл-13, (249)

что, бедняша, локалхост так навернул оно завсегда если мозгов нет 8212 то па, arisu (ok), 03:33 , 09-Июл-13, (251)

Не, ну вообще-то у него есть пойнт Я таким манером пару раз весьма изящно дурач, Аноним (-), 20:50 , 09-Июл-13, (327)

ну так специально можно и МПХ сломать, лишь бы цель такая стояла , arisu (ok), 21:57 , 09-Июл-13, (328) +1
У скуля как раз неприятная особенность в том что он слишком много всего умеет by, Аноним (-), 22:46 , 09-Июл-13, (329)
Прелесть кв не в блобятине - на блобятину можно и скуль заточить уже ж говорил , AlexAT (ok), 00:15 , 10-Июл-13, (336)
Прелесть - в том что k v 1 Затачивать не надо - ему индиффирентно чего жрать с , Аноним (-), 12:47 , 10-Июл-13, (348)
это не программер, это быдлокодер быдлокодер что угодно испортит , arisu (ok), 16:15 , 10-Июл-13, (354) +1
Нормальный спец по скулю, который реально понимает что реально будет сделано в о, Аноним (-), 18:44 , 11-Июл-13, (360)
ой, как будто на k v не делают таких ужасов, когда смотришь и офигеваешь , arisu (ok), 21:20 , 11-Июл-13, (362)

Да даже тот же MySQL Embedded можно встроить без особых проблем Вопрос только в, AlexAT (ok), 07:30 , 09-Июл-13, (254)

Но лучше ты его себе куда-нибудь встрой Ибо сдавать экзамен на пилотирование бо, Аноним (-), 14:06 , 09-Июл-13, (298)

А, ну так и скажите - порог вхождения не все осиляют Это да, факт Другое дело, , AlexAT (ok), 00:00 , 10-Июл-13, (333)

Более того - по этому поводу большинство запросов на скуле - дикий ужас Подавля, Аноним (-), 13:13 , 10-Июл-13, (349)

Автомобилей тоже больше, чем скутеров , AlexAT (ok), 14:22 , 10-Июл-13, (352)

А автомобиль по управлениию ближе к скутеру чем к боингу Ы , Аноним (-), 18:45 , 11-Июл-13, (361)

Я не думаю , я видел эту либу лично и даже в ее кишках немного копался по техни, Аноним (-), 14:05 , 09-Июл-13, (297) –1

Ну, раз вы покопались в кишках, то расскажите нам, чем уникальны курсоры в BDB , northbear (??), 00:24 , 11-Июл-13, (358)

Кстати, lmdb шикарная вещь, по тестам делает berkeley , Anonymouz (?), 17:00 , 09-Июл-13, (315) //

да и работает, вроде как, весьма стабильно у меня, правда, не гигабайтные объём, arisu (ok), 17:21 , 09-Июл-13, (317)

Лета не получилось Вот почему анонимные школьники бороздят в просторах интернет, kombat (ok), 06:05 , 10-Июл-13, (342) –1 //

Как мне вас жаль Sh t happens , Аноним (-), 13:15 , 10-Июл-13, (350)

ВНЕЗАПНО Оракле начали всё правильно делатьНо автор букв немного наркоман Но не , GG (ok), 22:48 , 10-Июл-13, (355)

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

113. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 08-Июл-13, 07:19

Я в курсе. Но из embedded движков логичнее выбрать SQLite, если конечно параллелизм на записи не требуется. И - да - любой реляционный движок легко позволяет сэмулировать key-value storage :)

Ответить | Правка | Наверх | Cообщить модератору

117. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –5 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 09:57

> Berkeley DB входит в числе базовых библиотек, от которых зависят многие пакеты. В связи с этим поставлен вопрос, допустима ли поставка базовых библиотек под AGPLv3, так как связывание с AGPLv3-библиотекой приведёт к распространению лицензии AGPLv3 на все использующие данную библиотеку пакеты.
Не ужели? да как они могли.. А вот когда gcc такую шутку провернул с libgcc - все дружно набрали воды в рот.. И ставили столмана..

Ответить | Правка | Наверх | Cообщить модератору

124. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от klalafuda (?), 08-Июл-13, 10:46

> Не ужели? да как они могли.. А вот когда gcc такую шутку провернул с libgcc - все дружно набрали воды в рот.. И ставили столмана..
RTFM однако: http://www.gnu.org/licenses/gcc-exception-faq.html
Что впрочем не удивительно - быстрой смерти GCC после полного перевода рантайма на честный *GPL никому не нужно.

Ответить | Правка | Наверх | Cообщить модератору

128. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –2 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 11:36

что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него..
Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.

Ответить | Правка | Наверх | Cообщить модератору

129. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от klalafuda (?), 08-Июл-13, 11:44

> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.
Я не в курсе деталей этой истории, но лично мне ничего удивительного в ней не видится. Полагаю, что сперва Столман & K решили как водится 'до основания а затем'. Но чуть позже трезвые товарищи по партии доходчиво объяснили им, что столь радикально делать не стоит. Иначе они останутся со своим полностью свободным GCC в гордом одиночестве в том числе без толстых спонсоров. Благо, конкурентов GCC хватает.

Ответить | Правка | Наверх | Cообщить модератору

137. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 14:06

Вот вот.. Пусть делают свой самый свободный компилятор..
А то "ложечки нашлись - но ведь осадочек остался" ?
Что еще эта компания сделает?
Хотя вот разработчики Debian оказались не рады AGPL v3.. почему - не подскажете ?

Ответить | Правка | Наверх | Cообщить модератору

143. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 08-Июл-13, 15:25

> Хотя вот разработчики Debian оказались не рады AGPL v3.. почему - не подскажете ?
удаки и идоры потому что. Сегодня лишний раз в этом убедился (да, и это никак не относилось к лицензионным вопросам).

Ответить | Правка | Наверх | Cообщить модератору

155. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от northbear (??), 08-Июл-13, 15:56

> Благо, конкурентов GCC хватает.
Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать. Но именно эта история спровоцировала бурное развитие Clang/LLVM.
Видать Oracle патологически не способен учиться на чужих ошибках...

Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

171. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –2 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 16:22

>> Благо, конкурентов GCC хватает.
> Конкурентов у GCC практически нет... Clang/LLVM только-только начал ядро более-менее собирать.
> Но именно эта история спровоцировала бурное развитие Clang/LLVM.
наверно вы помните - что ядро Clang собирал уже давно. Но слишком много "программистов" не знаю слово "стандарт на язык", а пишут как привыкли/научили - с кучей компиляторо-зависимого кода.
Могу больше сказать - попытка собрать ядро при помощи gcc с флагами -pedantic обречена на неудачу - в основном из-за такой вот кривизны кода.

Ответить | Правка | Наверх | Cообщить модератору

231. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от northbear (??), 09-Июл-13, 02:25

> наверно вы помните - что ядро Clang собирал уже давно.
Давно это 2-3 года? Сравните например с возрастом проекта GNU GCC (1987 год) или Linux-ядра (1991 год). Это то, что я называю словом давно. А Clang еще младенец, хоть и невероятно продвинутый...

Ответить | Правка | Наверх | Cообщить модератору

175. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от klalafuda (?), 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 (??), 09-Июл-13, 02:35

> Как раз сборка ядра - это совсем не показатель. Его можно собирать
> всем, чем угодно.
Я молча развожу руками... Может продемонстрируете?

Ответить | Правка | Наверх | Cообщить модератору

236. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +1 +/–

Сообщение от arisu (ok), 09-Июл-13, 02:36

tcc когда-то собирал ядро прямо при загрузке. было забавно.
интересно, способен ли он до сих пор на такой фокус?

Ответить | Правка | Наверх | Cообщить модератору

239. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." –1 +/–

Сообщение от northbear (??), 09-Июл-13, 03:03

> tcc когда-то собирал ядро прямо при загрузке. было забавно.
> интересно, способен ли он до сих пор на такой фокус?
ТССBOOT собирал адаптированные исходники собранные в ISO-образ. ТСС ничего не знает про расширения системы команд x86 типа SSE/SSE2. Я уже не говорю про код KVM в ядре...

Ответить | Правка | Наверх | Cообщить модератору

241. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +1 +/–

Сообщение от arisu (ok), 09-Июл-13, 03:05

вообще-то с тех пор tcc значительно подрос. и да: ядро таки может работать и без sse, и даже без kvm.

Ответить | Правка | Наверх | Cообщить модератору

279. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." –1 +/–

Сообщение от Аноним (-), 09-Июл-13, 12:43

> работать и без sse, и даже без kvm.
Ну да, а еще можно руку ампутировать. Печатать на клавиатуре и одной рукой можно. Зачем тебе лишние запчасти?!

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

290. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +1 +/–

Сообщение от arisu (ok), 09-Июл-13, 13:45

> Ну да, а еще можно руку ампутировать. Печатать на клавиатуре и одной
> рукой можно. Зачем тебе лишние запчасти?!
а зачем мне в ядре sse и kvm? не «зачем оно вообще надо?», а «зачем оно лично мне?»

Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

305. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." –1 +/–

Сообщение от Аноним (-), 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__ (?), 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 +/–

Сообщение от Аноним (-), 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 (?), 09-Июл-13, 11:16

> Я молча развожу руками... Может продемонстрируете?
"Его можно собирать всем, чем угодно." с точки зрения лицензии тулчейна и его обвязки. Это никак не повлияет на требования к лицензированию программ в userland-е.

Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

272. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Led (ok), 09-Июл-13, 12:22

>> Как раз сборка ядра - это совсем не показатель. Его можно собирать
>> всем, чем угодно.
> Я молча развожу руками... Может продемонстрируете?
icc, open64, tcc

Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

181. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +1 +/–

Сообщение от Andrey Mitrofanov (?), 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__ (?), 08-Июл-13, 21:49

>>> что удивительно - это exception появился очень не сразу. сначала 4.3 был выпущен без него.. Вы об этом забыли?... и только 4.4 (если не путаю) был выпущен с linking exception.
>> Я не в курсе деталей этой истории, но лично мне ничего удивительного
>> в ней не видится. Полагаю, что сперва Столман & K решили
> Спасибо, что спросили! :)
> Исключение про рантайм там было чуть не с созданья мира.
> "Просто" при переходе на GPLv3+ его не пофиксили под все [новые] "крайние"
> случаи. Это было сделано _сразу же_ по обнаружении (=рипорте о) проблемы,
> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.
вы серьезно верите что поменяв лицензию - народ не задумывался о том что менять надо и linking exception?
юристы типа "забыли"? вам самому не смешно? вы уверены что больше ничего не забыли такого что выйдет боком через N лет ?
Ну да - а пофиксили когда их макнули в это дерьмо - что так дела не делают.. а если бы не ткнули - так бы и работало все.

Ответить | Правка | Наверх | Cообщить модератору

224. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +2 +/–

Сообщение от Andrey Mitrofanov (?), 08-Июл-13, 22:49

>> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.
> вы серьезно верите что поменяв лицензию - народ не задумывался о том
Мартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала.
Святой отец, б., "веруешь ли", да, "веруешь ли".

Ответить | Правка | Наверх | Cообщить модератору

262. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от linux must __RIP__ (?), 09-Июл-13, 11:54

>>> в т.ч. _отдельно_ для уже выпущенных с кривым-старым исключением версий.
>> вы серьезно верите что поменяв лицензию - народ не задумывался о том
> Мартышка к старости слаба ушами стала -- всё переспрашивала, да, переспрашивала.
> Святой отец, б., "веруешь ли", да, "веруешь ли".
а по теме сказать чего-то есть? я вижу только веру в великого..

Ответить | Правка | Наверх | Cообщить модератору

280. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 12:45

> а по теме сказать чего-то есть? я вижу только веру в великого..
Да какая там вера? Обычный жирный троллинг всяких глупых личностей. Они, кстати, ведутся. Хоть и жирнота, казалось бы. Все-таки Митрофанов - талант. Так жирно потроллить чтобы на это какой-то лузер еще и купился - это талант иметь надо :)

Ответить | Правка | Наверх | Cообщить модератору

154. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 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), 08-Июл-13, 15:59

> В базу key-value такого плана заиньектить левак невозможно
И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set.
> Вот только скорость работы что-то не эмулируется.
А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать.

Ответить | Правка | Наверх | Cообщить модератору

166. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 08-Июл-13, 16:17

> И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set.
Ты издеваешься или как? Можно взять готовое решение которое работает быстро и безграбельно, а можно др@читься с выписыванием костылей самому + просесть в скорости. Нафиг надо такое "счастье"?
В нормальном виде сие должны были делать по людски разработчики скулайта, предоставив простое и низкоуровневое апи к его фактической реализации хранилища. Но это не было их целью, как соедует из названия. У них SQL головного мозга и баста. Если тебе нравится забивать гвозди микроскопом - флаг тебе в руки делать key-value из скулайта. А мне если уж AGPL так сильно дорогу перейдет, я какой-нить токийский кабинет возьму скорее.
И да, обычно в таких базах можно выбирать довольно низкоуровневые параметры стоража, которые иногда довольно сильно роялят. В частности - хэш-таблица, б-дерево, etc. Они разные по свойствам и в зависимости от ситуации - оптимальнее или так, или эдак. А в скулайте такое вообще хрен выберешь вообще.
> А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать.
Я не собираюсь бросать все и подрываться изучать новый ЯП (SQL) на уровне супергуру который умеет запросы профайлить. Тем более что там IIRC нет относительно низкоуровневых опций управления логикой стоража на уровне самых основ технологий хранения. А иногда удачный выбор таких опций может скорость в разы поднять. На скулайте придется пыхтеть в разы больше, а скорость будет в разы ниже.

Ответить | Правка | Наверх | Cообщить модератору

168. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 08-Июл-13, 16:20

> Ты издеваешься или как?
Да нет. Мне просто ехать, а не шашечки.

Ответить | Правка | Наверх | Cообщить модератору

172. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 16:23

>> Ты издеваешься или как?
> Да нет. Мне просто ехать, а не шашечки.
ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB ?

Ответить | Правка | Наверх | Cообщить модератору

179. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от klalafuda (?), 08-Июл-13, 16:35

> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в BDB ?
Вы таки серьезно считаете, что в том же SQLite на бакенде текстовый файл со строчками INSERT INTO Table VALUES (1, "John"), (2, "Doe") ?

Ответить | Правка | Наверх | Cообщить модератору

183. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 08-Июл-13, 16:37

Нет, там конечно бинарный стораж, но простой и быстрой дорожки его дернуть не дадено, равно как и управлять его базовыми свойствами.
А общаться с ним через призму парсера скуля - совершенно отдельная история. Парсер потратит немало времени на разбор конструкции и не факт что это будет оптимально.
С другой стороны хорошая база ключ-значение как правило укладывается в всего 2 дисковые операции на извлечение записи + минимальная нагрузка на проц.

Ответить | Правка | Наверх | Cообщить модератору

199. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от AlexAT (ok), 08-Июл-13, 17:57

> Парсер потратит немало времени на разбор конструкции и не факт что
> это будет оптимально.
Два слова: "prepared statements" - о чём-нибудь говорят?

Ответить | Правка | Наверх | Cообщить модератору

218. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –3 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 21:50

>> Парсер потратит немало времени на разбор конструкции и не факт что
>> это будет оптимально.
> Два слова: "prepared statements" - о чём-нибудь говорят?
говорит - что исполнение байт кода - всегда дольше чем просто поиск по базе key-> value.
Кстати как там с SQLite с поддержкой транзакционного стораджа?

Ответить | Правка | Наверх | Cообщить модератору

252. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 09-Июл-13, 07:16

> говорит - что исполнение байт кода - всегда дольше чем просто поиск
> по базе key-> value.
Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными. В остальных случаях накладные расходы будут несущественны.
Не забывайте, что у KV обычно всё атомно плохо с индексацией и произвольным поиском. Плюсы от возможности вести поиск по связям и наборам полей могут и перевесить минусы от наличия разборщика запросов. Не везде, естественно.
Во всяком случае, Subversion уже использует SQLite в клиентской части. Очевидно, осознали плюсы.
> Кстати как там с SQLite с поддержкой транзакционного стораджа?
А там иных не бывает... огромная проблема SQLite - необходимость блокирования всего файла при записи. Коммиты у SQLite атомарные, поэтому с конзистентностью всё более-менее. Не хуже, чем у BDB, во всяком случае.

Ответить | Правка | Наверх | Cообщить модератору

257. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от klalafuda (?), 09-Июл-13, 11:05

> Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными.
Ага. Особенно если нужно обработать данные из таблички с парой-тройкой десятков-сотен миллионов записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.

Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

263. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от linux must __RIP__ (?), 09-Июл-13, 11:56

>> Если обращения к KV store в inner loop - да, разница будет. Но обычно обращения к БД во внутренних циклах - крайне плохой тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными.
> Ага. Особенно если нужно обработать данные из таблички с парой-тройкой десятков-сотен миллионов
> записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.
не надо издеваться с детей :-) вот к примеру filldir() вполне себе выполняется внутри inner loop у dx dir аналогом которого является bdb и таких примеров чуть более чем дофига..

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

270. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 09-Июл-13, 12:09

> не надо издеваться с детей :-) вот к примеру filldir() вполне себе
> выполняется внутри inner loop у dx dir аналогом которого является bdb
> и таких примеров чуть более чем дофига..
Ну... ручки-то они - вона какие...

Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

330. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 09-Июл-13, 23:55

Вот, лакмусовая бумажка на крап-дезигнеров сработала. Если у вас случилась ситуация (shit happens, yeah), что вам надо из KV более одного раза за время жизни с последнего апгрейда вот так вот выгрести и обработать сотню миллионов записей - "поздравляю, Шарик, вы балбес"... выбор KV для задачи не то, что не оправдан, а вообще симптоматичен.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

339. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +1 +/–

Сообщение от Аноним (-), 10-Июл-13, 02:24

> задачи не то, что не оправдан, а вообще симптоматичен.
Тем не менее, справедливости ради - сиквельная будет вычитывать записи ничуть не хуже самопала. А при шит дизайнере с select * from, столь типичном для скрипткиддисов... - скульная база натурально все сотни миллионов записей будет лопатить ничуть не хуже.
Грамотно юзать скуль и понимать во что по факту оно будет трансформировано (дисковая активность, etc) умеет сильно немного народа - это отдельный класс крутых DBA/опытных SQL программеров, в общем свой заводик по производству ракет, со своим рокетсайнсом и инженерами. Вот так с наскока это взять вообще не варинт. Грамотно юзать k/v на порядок проще. Просто потому что он примитивный.

Ответить | Правка | К родителю #330 | Наверх | Cообщить модератору

338. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +1 +/–

Сообщение от Аноним (-), 10-Июл-13, 02:20

> записей (читать 'дохрена'). Высосем её сперва в память. Всю. Че там.
Если тебе приходится это делать с K/V - ты что-то делаешь не так. Совсем не так.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

265. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от linux must __RIP__ (?), 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, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 12:51

> Два слова: "prepared statements" - о чём-нибудь говорят?
Здравый смысл и понимание алгоритмов говорят мне что лукап по b-дереву или хэш-таблице априори быстрее чем нечто аналогичное + пакости от парсера невъ...нного языка и вагон костылей для их воркэраундинга.
Но ты в своем праве делать из сиквельной базы key-value. Но лично я не понимаю в чем пойнт сначала сильно усложнить себе жизнь, сначала донавесив поверх хранилища парсер, а потом героически воевать с ветряными мельницами, пытаясь отделаться от его проблем, чтобы в результате ... получить нативное представление сущностей в хранилище? Да ты больной. Проще сразу не навешивать парсер чем воевать с его фирменными граблями типа тормозов, иньекций и прочих радостей жизни.

Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

306. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 09-Июл-13, 14:43

Ты так и не понял сути. Основная проблема - не в том, что нет KV на замену, а в том, что KV пихают даже туда, где он в принципе убыточен.
А речь изначально шла о том, что в ряде проектов BDB можно заменить на embedded SQL/embedded NoSQL. Чего накинулся - непонятно.

Ответить | Правка | Наверх | Cообщить модератору

322. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 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), 08-Июл-13, 17:56

> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
> BDB ?
Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того, что работа с BDB - не основная операция.

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

219. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –2 +/–

Сообщение от linux must __RIP__ (?), 08-Июл-13, 21:50

>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
>> BDB ?
> Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того,
> что работа с BDB - не основная операция.
у кого как :-)

Ответить | Правка | Наверх | Cообщить модератору

243. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 03:07

> у кого как :-)
Ну, у юнит-тестов BDB все, конечно, иначе...

Ответить | Правка | Наверх | Cообщить модератору

282. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 12:56

> Я считаю, что в конкретных юзкейсах разница будет ничтожна за счёт того,
> что работа с BDB - не основная операция.
А это как бы весьма зависит от. Такие базы ставят там где скорость работы с базой все-таки интересовала. При этом сознательно идут на упрощение абстракций и их примитивизацию в пользу скорости работы + можно не париться экранированием (которое для больших объемов данных опять же тормознет все). Все-равно заиньектить в базу принимающую любые данные как  ключ и значение технически невозможно.

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

307. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." –1 +/–

Сообщение от AlexAT (ok), 09-Июл-13, 14:46

> Такие базы ставят там где скорость работы с базой все-таки интересовала.
Особенно в том же SVN, агаугу. Или в PAM. Там и SQL нахрен не впёрся, конечно, но в целом от скорости работы с самим форматом базы там ничего не меняется - не там основная нагрузка.

Ответить | Правка | Наверх | Cообщить модератору

323. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 20:39

> Особенно в том же SVN, агаугу.
Ой, как они им пользуются - я без понятия. Не интересуюсь некромансией. В git например свой самопальный кастомный формат хранения объектов везде, т.к. все это очень чувствительно к скорости.
> Или в PAM.
Как бы в таких применениях ситуация бывает разной. Какой-нибудь контроллер домена например может обслуживать десятки тысяч авторизаций в секунду. И я не вижу ни одной валидной причины по которой PAM имел бы право умирать под такими нагрузками. Лучше пусть запас производительности будет чем наступит ж@па.
> Там и SQL нахрен не впёрся, конечно, но в целом от скорости работы с
> самим форматом базы там ничего не меняется - не там основная нагрузка.
Зато прилетевший на что-то типа контроллера домена скуль иньекшн от бобби тэйблса энтерпрайзникам точно понравится :). Ибо раздестроить нечто типа активной директории или ее аналога 1 запросом - сказочная мечта любого кулхацкера :).

Ответить | Правка | Наверх | Cообщить модератору

253. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 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__ (?), 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-сторейдже к примеру. Сейчас их
> вагон, и отказываться от удобства - тупо.
Да да. А перегружать задачи не нужной функционостью - это ооочень правильно. И терять в скорости тоже..
как это похоже на современных программистов - которые вырезают гланды автогеном..

Ответить | Правка | Наверх | Cообщить модератору

283. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 13:28

> Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В
> SQL-based движках в основном всё те же btree :) на подложке.
Вот только сперва донавесить парсер, а потом путем длительной борьбы задеградировать его до "почти b-дерева" - бессмысленно и беспощадно. Куча времени будет убита ни на что!
- Придется изучить SQL.
- Придется изучить сколько времени и где тратится.
- Придется очень хорошо раздуплять как оно план выполнения кроит и прочая.
- И как это потом трансформируется в дисковую активность.
- И как это "хакнуть" чтобы этот бредогенератор минимизировал свои операции и вообще интерференцию.
- Придется делать экранирование.
- Итоговая скорость даже в самом идеальном случае будет несколько хуже. В реальном случае, с разумными затратами сил, без месяца профилировки и войны с парсером/планировщиком выполнения - оно скорее всего сольет в несколько раз.
> А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на
> большие расстояния.
При всем уважении, автомобиль не заменяет велосипед.

Ответить | Правка | К родителю #253 | Наверх | Cообщить модератору

308. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 09-Июл-13, 14:47

> При всем уважении, автомобиль не заменяет велосипед.
В 1% случаев - не заменяет. Попытки проехать на велосипеде от Москвы до хотя бы СПб - ну чего, флаг в руки.

Ответить | Правка | Наверх | Cообщить модератору

324. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 20:40

> В 1% случаев - не заменяет. Попытки проехать на велосипеде от Москвы
> до хотя бы СПб - ну чего, флаг в руки.
Да фигня вопрос! Кладем в багажный отсек поезда/самолета и едем :).

Ответить | Правка | Наверх | Cообщить модератору

180. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 08-Июл-13, 16:35

> Да нет. Мне просто ехать, а не шашечки.
Мне тоже. И мне совершенно не улыбается идея опилить сначала самосвал до легковушки а потом еще и удивляться - ой, а чего это он даже по идеальному шоссе выше 80 км/ч вообще никак? :)

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

201. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +1 +/–

Сообщение от AlexAT (ok), 08-Июл-13, 19:00

Я согласен, что для KV лучше использовать именно KV сторейджи. Но в приличном ряде случаев, а особенно там, где для KV применялся BDB - разница вряд ли будет ощутимой. Плюс вполне возможно, что польза/выигрыш от перехода на SQL с индексами и произвольными выборками будет больше, чем от собственно архитектуры KV.
PS. Очепятался.

Ответить | Правка | Наверх | Cообщить модератору

286. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 13:35

> Я согласен, что для KV лучше использовать именно KV сторейджи. Но в
> приличном ряде случаев, а особенно там, где для KV применялся BDB
> - разница вряд ли будет ощутимой.
KV обычно применяется тем где надо быстро лопатить много записей в примитивном виде. Скуль в этом случае ничего кроме головняка вообще не даст.
> Плюс вполне возможно, что польза/выигрыш от перехода на SQL с индексами
> и произвольными выборками будет больше, чем от собственно архитектуры KV.
В KV априори есть полный индекс по ключу, по другому оно просто работать не умеет :). Там негде выигрывать. Это и так одна из наиболее быстрых опций - непосредственный лукап в стораже без всякого промежуточного балласта. Скулю там негде выиграть по скорости, by design. По крайней мере в key-value применениях.
Скуль имеет смысл для навороченных иерархий с таблицами и прочая - на KV придется сделать то же самое но через тот еще зад и самому. Но если KV уже поюзан - значит задача совсем не о том была.

Ответить | Правка | Наверх | Cообщить модератору

309. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от AlexAT (ok), 09-Июл-13, 14:48

> KV обычно применяется тем где надо быстро лопатить много записей в примитивном
> виде. Скуль в этом случае ничего кроме головняка вообще не даст.
При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.

Ответить | Правка | Наверх | Cообщить модератору

312. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +1 +/–

Сообщение от arisu (ok), 09-Июл-13, 14:56

> При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.
а это называется «мы узнали модный баззворд». если в задаче часто требуется какое-то навороченое фильтрование, для которого никак не получается вывернуться, зашив нужную информацию в ключи, то авторы промахнулись с инструментом.

Ответить | Правка | Наверх | Cообщить модератору

325. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." +/–

Сообщение от Аноним (-), 09-Июл-13, 20:43

> При этом наблюдаются головняки в виде фильтрации диапазонов записей на уровне приложения.
Да вы, я так смотрю, эксперт по забиванию гвоздей микроскопом. Вы умеете сватать и скуль туда где он не уперся, и kv там где с ним сложно.
Тем не менее, некоторые k/v умеют сортировку записей и/или выборку диапазонов, если уж на то пошло. Насколько оно там подойдет в конкретном случае - вопрос номер два, смотреть надо. Но если подойдет - это будет круто и быстро, ибо все это на уровне нативного представления данных в стораже.

Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

207. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +1 +/–

Сообщение от arisu (ok), 08-Июл-13, 19:42

> Я в курсе. Но из embedded движков логичнее выбрать SQLite, если конечно
> параллелизм на записи не требуется.
LMDB: http://symas.com/mdb/

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

289. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." –1 +/–

Сообщение от Аноним (-), 09-Июл-13, 13:43

> LMDB: http://symas.com/mdb/
mmaped -> на 32-бит платформах лимитирована 4Гб. Это фэйл.

Ответить | Правка | Наверх | Cообщить модератору

299. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +1 +/–

Сообщение от arisu (ok), 09-Июл-13, 14:10

>> LMDB: http://symas.com/mdb/
> mmaped -> на 32-бит платформах лимитирована 4Гб. Это фэйл.
скажи, что у тебя за база размером в терабайты? и что за приложение, которое требует, чтобы ко всем этим терабайтам был рандомный доступ всегда? и почему там key/value, когда такие базы явно требуют более сложных выборок?
короче говоря, у тебя или понты ради понтов, или хреновое проектирование и неверно выбраный инструмент.
алсо, если ты ворочаешь такими объёмами данных, то почему у тебя x86? наверняка там сервер с кучей RAM, и лимитировать одну задачу четырьмя гигабайтами как-то очень глупо.

Ответить | Правка | Наверх | Cообщить модератору

303. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." –1 +/–

Сообщение от Аноним (-), 09-Июл-13, 14:33

> скажи, что у тебя за база размером в терабайты? и что за
> приложение, которое требует, чтобы ко всем этим терабайтам был рандомный доступ
> всегда? и почему там key/value, когда такие базы явно требуют более сложных выборок?
С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком примитивной и заменишь свою файловую систему на SQLную базу, ога :)
> короче говоря, у тебя или пoнты ради пoнтов, или хрeновое проектирование и
> неверно выбраный инструмент.
Короче говоря, это просто ничем не обоснованный буллшит. Простая и быстрая база вполне может катить для применений где хранится сколько-то гб данных. Отличный пример таких баз - файловые системы, которые по сути оно самое и есть. Ну разве что заоптимизировано под свои специфичные нужды. А по общей логике - напрашивается чтобы тебя потроллить этим применением за излишне generic'овые высказывания :).
> алсо, если ты ворочаешь такими объёмами данных, то почему у тебя x86?
Алсо, я могу прицепить 2-терабайтный винч к вон той 32-битной ARMовской платке по sata. Ничему не противоречит. А вот какой-то совершенно идиoтский лимит нарисовавшийся на ровном месте - двигуну совсем не в плюс.
Не, в целом смотрится любопытно, но вот это свойство все портит. Увы, я такое классифицирую как defective by design.

Ответить | Правка | Наверх | Cообщить модератору

335. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +/–

Сообщение от AlexAT (ok), 10-Июл-13, 00:04

> С нетерпением жду когда ты объявишь семантику доступа posix к файлам слишком
> примитивной и заменишь свою файловую систему на SQLную базу, ога :)
MS уже пыталась. Идея, кстати, неплоха, но опять же - не стоит ее везде лепить - только там, где нужен поиск по хреновой туче нечетких критериев.

Ответить | Правка | Наверх | Cообщить модератору

340. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +/–

Сообщение от Аноним (-), 10-Июл-13, 02:35

> MS уже пыталась.
Но зафэйлили. И если уж на то пошло, у MS есть собственный весьма забористый ESE storage engine который они никуда выкидывать не собираются и он больше ориентирован на простую но быструю работу нежели на навороты а-ля скуль.
Этот движок используется такими "незначительными" сущностями как active directory и exchange. При том что у MS, заметь, есть и сиквел-сервер, даже у MS хватает ума не впихивать это там где надо натурально быстрый доступ к базе без переусложнений которые бы реально потребовали скуль.
Я конечно понимаю что если упереться рогом в свой долбаный скуль то кажется что мир крутится вокруг него. Но если разуть глаза - можно обнаружить немало интересных фактов, отличающихся от вашего представления о серебряных пулях.
> Идея, кстати, неплоха, но опять же - не стоит ее везде лепить - только там,
> где нужен поиск по хреновой туче нечетких критериев.
В конечном итоге оказалось проще навесить внешний индексатор. И там тоже вроде как никаких скулей не пользуется. Вообще поражают потуги всучивать скуль во все щели, даже туда где он нафиг не уперся и создает только кучу проблем на ровном месте.

Ответить | Правка | Наверх | Cообщить модератору

343. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +/–

Сообщение от AlexAT (ok), 10-Июл-13, 07:20

> При том что у MS, заметь, есть и сиквел-сервер, даже у
> MS хватает ума не впихивать это там где надо натурально быстрый
> доступ к базе без переусложнений которые бы реально потребовали скуль.
Имхо просто переделывать некому пока. А насчет SQL - он у них даже в WMI представлен весьма себе неплохо - где он имхо совершенно не нужен.
> В конечном итоге оказалось проще навесить внешний индексатор.
Да и работает он... как внешний индексатор... Многие функцию "поддержки поиска" тупо отключают сразу после инсталла, потому что именно так и реализован.

Ответить | Правка | Наверх | Cообщить модератору

351. "Berkeley DB переведён на лицензию AGPLv3, что привело к..." +/–

Сообщение от Аноним (-), 10-Июл-13, 14:01

> Имхо просто переделывать некому пока.
Написать SQL сервак есть кому, написать ESE storage есть кому, а переделать некому? Как-то слишком притянуто за ущи звучит. Тем более что ESE и их SQL серверу вроде примерно одинаково лет, плюс-минус лапоть. Просто MS на заре своего развития умудрился набрать вменяемых спецов а не придурков с горящими глазами, лихо забивающих любимом микроскопом гвозди любого калибра. Поэтому с тех времен у них остался ряд достаточно продуманных решений, сделанных специалистами, с задействованием головы. Поэтому кроме всего прочего все это хозяйство работает с достаточно приличной скоростью на достаточно больших объемах данных, что актуально ынтырпрайзникам с AD о десятках миллионов объектов и многими гигазами почты. И даже с учетом безбашенного управления они еще все-таки не все полимеры проср@ли. Вот конкретно эти 2 до сих пор без лобовой замены пока. При желании заменить можно, но возни - будет. И не факт что будет работать так же хорошо. Одна из причин почему MS еще не послали во всех энтерпрайзах, несмотря на геморные условия лицензирования.
> А насчет SQL - он у них даже в WMI представлен весьма себе неплохо - где он имхо
> совершенно не нyжен.
Вот про это - ничего не знаю. Я расписывался лишь за то о чем более-менее в курсе.
> Да и работает он... как внешний индексатор... Многие функцию "поддержки поиска" тупо
> отключают сразу после инсталла, потому что именно так и реализован.
Неа, отключают просто потому что нафиг не упало - те у кого есть мозг обычно и так знают что у них и где лежит. Зачем мне индексатор, если я и так структурую хранение информации и могу быстро найти ее сам? А индексатор по любому будет жрать ресурсы - он по любому должен файлы парсить. Чудес не бывает.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


	305. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."	–1 +/–
	Сообщение от Аноним (-), 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__ (?), 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 +/–
	Сообщение от Аноним (-), 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 (?), 09-Июл-13, 11:16
	> Я молча развожу руками... Может продемонстрируете? "Его можно собирать всем, чем угодно." с точки зрения лицензии тулчейна и его обвязки. Это никак не повлияет на требования к лицензированию программ в userland-е.
	Ответить \| Правка \| К родителю #234 \| Наверх \| Cообщить модератору


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


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


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


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


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


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


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