Мне надо ядро 5.4+ и компилятор с поддержкой лямбд C++. Не уверен, что у них это есть — компилятор же закрытый. Больше того, они GPL нарушают в binutils — патченый binutils распространяют, а исходники к нему не дают.
Собственно, в binutils есть objdump и когда они таки перестанут нарушать GPL — вся их Секретная Документация По Опкодам (тоже бред тот ещё, процессор с закрытой системой команд) в тот же момент перестанет быть секретной. В общем такая себе политика — как линуксы открытые запускать, так в первых рядах, а как GPL соблюсти…
Ну и железо само в конце концов тоже не сказать чтобы просто взять, да :)) ещё и с дисками.
Intel (128k, T8Q32 read) = 2618 MB/s, то есть 20944 iops (1 io = 128 KB), то есть задержка ~12 мс
E2K (128k, T8Q32 read) = 2918 MB/s, то есть 23304 iops, то есть задержка ~11 мс
Откуда взяты цифры 0.4 и 5 мс — неизвестно, взяты с неба.
Ваш продукт не опенсорс. Бинарь под MIT открыть — это не опенсорс. :-) не называйте его опенсорсом.
Ну и (я уж не знаю, ВДРУГ вы этого не осознаёте) при желании всё всегда можно расшифровать. Кому оно конечно надо… Ну, если бы мне было надо, я бы из принципа расшифровал, да :-)
А так, если по делу — ну такая себе попытка сделать свой 1С-ик. Ну, нормальная идея, но она, в общем-то, очевидная. Будет ли успех — зависит от реализации.
Но в целом заниматься шифрованием кода — это какая-то фигня, нормальные проекты таким не занимаются.
Не, ну стоп. Терабайт в яндекс диске стоит 209 р в месяц. Это вполне себе 2500 рублей в год. Жёсткий диск 1 ТБ стоит даже чуть подешевле :-). Ясно, что ещё инфраструктура, избыточность, трафик и вот это вот всё, но и люди этим пользуются не 1 год, так что 209 р в месяц за 1 ТБ — это не так уж и дёшево.
Да тупо даже если сам будешь пользоваться 5 лет, то это уже 12.5к и за эти деньги можно себе микроNAS организовать на одноплатнике каком-нибудь, причём даже не 1 ТБ пожалуй. Ну, днище, но и то быстрее будет работать, чем облако )))).
В backblaze тоже сравнимо, 60$ в год и безлимитный объём. Ну т.е. даже дешевле если > 1 ТБ. А там хранят больше.
Так что чего яндекс там вдруг решил, что за эту цену туда бэкапиться нельзя — не понятно. // Место наверное на хардах кончилось :D
Чего там ещё-то хранить терабайтами, кроме бэкапов вообще?
Ну так да, это и называется «делаем всё что хотим, а дурак по умолчанию пользователь» :-)
Правила должны быть такие, что всё, что явно не запрещено — разрешено и споры все в пользу юзера, а не компании. По сути беспредел с этим, никакого регулирования нет (госдумы на них нет)
Ну по идее надо просто расковырять андроид клиент яндекс диска и выдрать ключ оттуда. И пусть блокируют собственный клиент. :-)
Можно ещё в телеграм чате яндекс облака набросить на вентилятор. А то они всё хотят, чтобы там радужная атмосфера была.
Хотя, с другой стороны, нужны они? Более правильным советом будет просто не юзать облака до тех пор, пока у них не появится нормальный договор, а не «вы отдаёте нам всё и ещё соглашаетесь что мы с вами будем делать всё что захотим». Я лично не юзаю.
А то с гугл драйвом в принципе аналогичная фигня — я совершенно случайно grive2 поддерживаю, и эти умники вообще закрыли API для client_id, не «прошедших верификацию».
блин, но у вас бы хоть IDLE был. ладно NOTIFY (редкая вещь), но хоть IDLE… и QRESYNC… а щас в итоге ни фига нет до сих пор) вы кстати там ещё работаете? есть какие-нибудь планы по развитию IMAP сервера?
Вы зря, это вполне нормальный подход, во многих крупных проектах применяется.
Смысл в том, что если фильтров много, их выгодно загнать в один инвертированный индекс. GIN — это инвертированный индекс и полнотекстовый индекс — это тоже инвертированный индекс, да и задача фактически одна и та же — взять несколько терминов, взять наборы документов, их содержащие, и пересечь. Полнотекстовый индекс получится один общий, поэтому будет даже ещё немного шустрее. Плюс туда же можно загнать и непосредственно текстовые описания, и тогда шустро работать будет ещё и поиск по тексту + фильтрам :-)
Да, плюс полнотекстовые движки умеют заодно и информацию о пресловутых агрегациях выдавать, их фасетами ещё называют, т.е. это ответ на вопрос «какие значения фильтров есть у найденных товаров?»
Вот что я бы сюда ещё реально добавил, постоянно глядя на жуткий разнородный код генерации HTML в MediaWiki: вы всё ещё выводите HTML print'ами? А может ?> <?php вставками? А может сборкой в строку или специально придуманными хелпер методами? Записывайте себе -30 очков… :)
А то фиг с ними, со сценариями сборки, но когда я вижу помесь PHP и HTML — вот уж где мамонты так мамонты...)) а оно живо… вон, вся медиавики так написана.
Ага… И ещё SHOW CREATE TABLE удобная тема. Причём в mysql это же всё не команды консольного клиента, а просто SQL запросы, то есть их и из скриптов можно дёргать — тоже удобно. Минус правда в том, что зачастую в mysql это единственный реальный способ вытащить какую-то информацию о таблице, т.е. приходится парсить show create table вместо того, чтобы просто посмотреть в нужное место каталога…
там ещё прикол в том что обязательно tsvector надо в таблице хранить, иначе очень медленно ранжирование работает.
был доклад «полнотекстовый поиск в postgresql за миллисекунды», где они грозились допилить его, чтобы он сам информацию из tsvector'а хранил, и тогда его скорость реально приближалась к Sphinx'у. но по-видимому пока что не сделали…
Собственно, в binutils есть objdump и когда они таки перестанут нарушать GPL — вся их Секретная Документация По Опкодам (тоже бред тот ещё, процессор с закрытой системой команд) в тот же момент перестанет быть секретной. В общем такая себе политика — как линуксы открытые запускать, так в первых рядах, а как GPL соблюсти…
Ну и железо само в конце концов тоже не сказать чтобы просто взять, да :)) ещё и с дисками.
iops = параллелизм / задержка
задержка = параллелизм / iops
Таким образом, например, у вас:
Intel (128k, T8Q32 read) = 2618 MB/s, то есть 20944 iops (1 io = 128 KB), то есть задержка ~12 мс
E2K (128k, T8Q32 read) = 2918 MB/s, то есть 23304 iops, то есть задержка ~11 мс
Откуда взяты цифры 0.4 и 5 мс — неизвестно, взяты с неба.
Ваш продукт не опенсорс. Бинарь под MIT открыть — это не опенсорс. :-) не называйте его опенсорсом.
Ну и (я уж не знаю, ВДРУГ вы этого не осознаёте) при желании всё всегда можно расшифровать. Кому оно конечно надо… Ну, если бы мне было надо, я бы из принципа расшифровал, да :-)
А так, если по делу — ну такая себе попытка сделать свой 1С-ик. Ну, нормальная идея, но она, в общем-то, очевидная. Будет ли успех — зависит от реализации.
Но в целом заниматься шифрованием кода — это какая-то фигня, нормальные проекты таким не занимаются.
Да тупо даже если сам будешь пользоваться 5 лет, то это уже 12.5к и за эти деньги можно себе микроNAS организовать на одноплатнике каком-нибудь, причём даже не 1 ТБ пожалуй. Ну, днище, но и то быстрее будет работать, чем облако )))).
В backblaze тоже сравнимо, 60$ в год и безлимитный объём. Ну т.е. даже дешевле если > 1 ТБ. А там хранят больше.
Так что чего яндекс там вдруг решил, что за эту цену туда бэкапиться нельзя — не понятно. // Место наверное на хардах кончилось :D
Чего там ещё-то хранить терабайтами, кроме бэкапов вообще?
Правила должны быть такие, что всё, что явно не запрещено — разрешено и споры все в пользу юзера, а не компании. По сути беспредел с этим, никакого регулирования нет (госдумы на них нет)
Можно ещё в телеграм чате яндекс облака набросить на вентилятор. А то они всё хотят, чтобы там радужная атмосфера была.
Хотя, с другой стороны, нужны они? Более правильным советом будет просто не юзать облака до тех пор, пока у них не появится нормальный договор, а не «вы отдаёте нам всё и ещё соглашаетесь что мы с вами будем делать всё что захотим». Я лично не юзаю.
А то с гугл драйвом в принципе аналогичная фигня — я совершенно случайно grive2 поддерживаю, и эти умники вообще закрыли API для client_id, не «прошедших верификацию».
Смысл в том, что если фильтров много, их выгодно загнать в один инвертированный индекс. GIN — это инвертированный индекс и полнотекстовый индекс — это тоже инвертированный индекс, да и задача фактически одна и та же — взять несколько терминов, взять наборы документов, их содержащие, и пересечь. Полнотекстовый индекс получится один общий, поэтому будет даже ещё немного шустрее. Плюс туда же можно загнать и непосредственно текстовые описания, и тогда шустро работать будет ещё и поиск по тексту + фильтрам :-)
Да, плюс полнотекстовые движки умеют заодно и информацию о пресловутых агрегациях выдавать, их фасетами ещё называют, т.е. это ответ на вопрос «какие значения фильтров есть у найденных товаров?»
Вот что я бы сюда ещё реально добавил, постоянно глядя на жуткий разнородный код генерации HTML в MediaWiki: вы всё ещё выводите HTML print'ами? А может ?> <?php вставками? А может сборкой в строку или специально придуманными хелпер методами? Записывайте себе -30 очков… :)
А то фиг с ними, со сценариями сборки, но когда я вижу помесь PHP и HTML — вот уж где мамонты так мамонты...)) а оно живо… вон, вся медиавики так написана.
Неказист конечно немного, но юзабелен в целом.
был доклад «полнотекстовый поиск в postgresql за миллисекунды», где они грозились допилить его, чтобы он сам информацию из tsvector'а хранил, и тогда его скорость реально приближалась к Sphinx'у. но по-видимому пока что не сделали…