lcc и есть форк gcc даже если не полностью то куски от туда они взяли… GPL лицензия требует открытие всего проекта если вы хоть что то взяли от GPL.
Про glibc, gcc они уже отвечали что "мы типо пилим для военных и мы чихали на ваш GPL".
Кроме того они правили Mesa, DRM и т.д. то же без фидбека сообществу. Короче пока они будут красть чужой труд я однозначно против их конторы. (пару раз был у них в гостях к слову пока учился в универе)
Это похоже на асинхронный UI. Собственно и проблемы от этого уже описаны выше.
По факту получается так — по умолчанию всё делает синхронным и только там где это точно никому не навредит делаем оптимистично/асинхронно.
ЗЫ к слову как однозначно определяется к примеру сообщение которое ещё не побывало на сервере? Ей на клиенте придумываем ID? Ведь когда от сервера придёт ответ надо точно понять о каком таске этот ответ.
Вопрос только как он это умеет… во многих usecases это крайне медленно. Ну и опять же лишние запросы туда сюда увеличивают время отклика.
т.е. если у вас задача по сути искать только по тексту то это наверное хороший вариант, а вот если полнотекстовый поиск у вас просто винтик в большой и связанной системе то лучше не отходить от кассы (postgres) далеко.
Для того что бы создать инкремент нужно вычитать ВСЮ бд т.е. прочитать каждую страницу и сверить её LSN.
Чем больше БД тем дольше занимает этот процесс. ptrack умеет отслеживать изменения памяти на лету с почти нулевым оверхедом (1-2%), а pg_arman умеет читать эту информации для того, что бы без каких либо лишних движений делать бекап.
Это необходимо не только для восстановления при сбоях, но и дает много интересных возможностей разработчикам для работы в определенных временных срезах базы. В PostgreSQL для этого есть barman.
Если у вас нагруженная БД то хранение WAL для PITR это боль. Кроме того создание инкрементального бекапа при помощи braman это отдельная боль (если у вас БД больше 100 гигов). Большую часть этих проблем я решаю тут pg_arman .
У меня основная претензия только, что это не native приложение и местами работает крайне медленно.
В Libre в последнее время очень сильно поработали над производительностью. (и там увы тот же не нативный GTK, Qt, Cairo или что то ещё, но всё же везде С++)
Во всей этой истории меня напрягает только дублирование функционала.
К примеру хотелось бы как то иметь возможность переиспользовать буфер менеджер из ядра эффективным способом.
В больших базах данных – Postgres, MySQL, InnoDB – в основном, используют O_DIRECT
Для справки оставлю тут: Postgres не использует O_DIRECT, а использует простой write и если надо сбросить несколько страниц из буфер менеджера делает mmap (но это редко).
Но да… у него свой Clock-SI буфер менеджер (на самом деле ещё RLU для CLOG к примеру).
Удар №2 — главная страница сайта сделана как раз в виде SPA и (как я потом уже посмотрел) грузит мне без спроса при заходе чуть ли не всю «галерею популярных товаров со скидками» метров на 5 размером
Меня в этом плане больше убивает сайт PSN, там при загрузке грузится 3-4 мегабайта json в архиве!!!
А всё потому, что они туда выгружают абсолютно всё и ещё рекурсивно.
т.е. пока сервер не ответил мы живём с временным случайно сгенреным ID а после того как сервер ответил уже с нормальным ID с сервера?
В целом ясно.
lcc и есть форк gcc даже если не полностью то куски от туда они взяли… GPL лицензия требует открытие всего проекта если вы хоть что то взяли от GPL.
Про glibc, gcc они уже отвечали что "мы типо пилим для военных и мы чихали на ваш GPL".
Кроме того они правили Mesa, DRM и т.д. то же без фидбека сообществу. Короче пока они будут красть чужой труд я однозначно против их конторы. (пару раз был у них в гостях к слову пока учился в универе)
Я почти уверен что у Postgres там есть проблемы… кто бы дал помучить.
откуда он взялся? Как его с генерировали? Как избежать коллизий?
Это похоже на асинхронный UI. Собственно и проблемы от этого уже описаны выше.
По факту получается так — по умолчанию всё делает синхронным и только там где это точно никому не навредит делаем оптимистично/асинхронно.
ЗЫ к слову как однозначно определяется к примеру сообщение которое ещё не побывало на сервере? Ей на клиенте придумываем ID? Ведь когда от сервера придёт ответ надо точно понять о каком таске этот ответ.
Я всё жду того когда они откроют свои форки gcc и glibc как того требует лицензия. Тогда и будет понятнее про оптимизации и прочее.
Вопрос только как он это умеет… во многих usecases это крайне медленно. Ну и опять же лишние запросы туда сюда увеличивают время отклика.
т.е. если у вас задача по сути искать только по тексту то это наверное хороший вариант, а вот если полнотекстовый поиск у вас просто винтик в большой и связанной системе то лучше не отходить от кассы (postgres) далеко.
Это всё хорошо пока не надо учитывать ещё какое поле в запросе.
https://habrahabr.ru/post/179399/
Для того что бы создать инкремент нужно вычитать ВСЮ бд т.е. прочитать каждую страницу и сверить её LSN.
Чем больше БД тем дольше занимает этот процесс. ptrack умеет отслеживать изменения памяти на лету с почти нулевым оверхедом (1-2%), а pg_arman умеет читать эту информации для того, что бы без каких либо лишних движений делать бекап.
Если у вас нагруженная БД то хранение WAL для PITR это боль. Кроме того создание инкрементального бекапа при помощи braman это отдельная боль (если у вас БД больше 100 гигов). Большую часть этих проблем я решаю тут pg_arman .
У меня основная претензия только, что это не native приложение и местами работает крайне медленно.
В Libre в последнее время очень сильно поработали над производительностью. (и там увы тот же не нативный GTK, Qt, Cairo или что то ещё, но всё же везде С++)
Очень надеюсь что вот они https://www.calligra.org/ смогут взлететь, идеи там крайне верные ИМХО.
Во всей этой истории меня напрягает только дублирование функционала.
К примеру хотелось бы как то иметь возможность переиспользовать буфер менеджер из ядра эффективным способом.
Для справки оставлю тут: Postgres не использует O_DIRECT, а использует простой write и если надо сбросить несколько страниц из буфер менеджера делает mmap (но это редко).
Но да… у него свой Clock-SI буфер менеджер (на самом деле ещё RLU для CLOG к примеру).
Мне нравится синтаксис Stylus...
Очень желательна GCN 1.1 и выше.
Зато вот Rust начинает прокладывать дорогу в GameDev!
т.е. без публичного IP не потестить её?
Меня в этом плане больше убивает сайт PSN, там при загрузке грузится 3-4 мегабайта json в архиве!!!
А всё потому, что они туда выгружают абсолютно всё и ещё рекурсивно.
Очень надеюсь, что blink переломит ситуацию.
Mozilla делает много интересных и открытых проектов.
ЗЫ пользователь Chromium