• Маленький ноутбук для системного администратора
    0
    Наблюдение касаемо практической реализации идеи. Если отказаться от алюминиевого корпуса, его можно будет напечатать на 3D принтере. Берем одноплатник по вкусу, закупаемся на eBay LVDS-дисплеем и клавиатурой (или извлекаем из старых ненужных ноутбуков, коих у любого IT-шинка обычно несколько, ну или если не у него, то у его коллег), и вот уже почти готовый ноут.
  • DSP на Java
    0
    Спасибо за проделанный труд и статью, очень интересно.

    Было бы круто, если бы вы подробнее разжевали алгоритмы DSP и их реализацию на Java, так как тема эта довольно сложна для восприятия, во всяком случае, на мой вкус. Ну или хотя бы посоветовали бы литературу по этой теме.
  • Безопасно ускоряем Erlang приложение c помощью NIF на Rust
    0
    Почитал тут erlang.org/doc/man/erl_nif.html#lengthy_work

    Мне кажется секция Yielding NIF больше похожа на правдоподобное решение.
  • Безопасно ускоряем Erlang приложение c помощью NIF на Rust
    +1
    Спасибо, интересно. Сам в свое время писал NIF'ы (тынц), правда на C.

    На мой взгляд, опасность переполнения буфера или разыменования не того что нужно немного преувеличена. Куда бОльшая проблема, о которой часто тактично умалчивают, заключается в том, что NIF блокирует тред на котором он выполняется и вместе с ним исполняемые на нем акторы. Для быстрых вычислений это не проблема, но для сериализации/десериализации/кодирования/сжатия пары мегабайт данных проблема очень даже актуальная.

    Я слышал, что проблему отчасти решили в последних релизах Erlang'а, но, увы, не знаю деталей. Вроде как можно запустить сишный код на отдельной нитке ОС или вроде того.
  • И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках
    0
    Я не эксперт по sqlinj, но по моим представлениям конкретно в случае с PostgreSQL прочитать произвольный файл не так-то просто. И записать какой-нибудь шелл тоже, если СУБД ставилась из обычного пакета, а не из исходников например, запускаясь под юзером www.
  • И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках
    0
    Скорее всего, да. Соль в конфиге, хэш от пароля + эта соль. Или хэш 1000 раз в цикле, например.
  • JetBrains CLion для микроконтроллеров
    +2
    Иронично, но благодаря вашей статье я вдруг наконец-то понял, как правильно писать под STM32 без IDE :) Просто не знал что scaffolding проекта нужно делать через STM32CubeMX ровно как и то, что эта программа превосходно работает под Linux. А без scaffolding сами понимаете как это трудно. Большинство же туториалов для начинающих написаны в стиле «качаем InstallIDE.exe, и жмем в кнопочки так-то и так-то». В любом случае, спасибо большое за пост!
  • Индексы в PostgreSQL — 5
    +5
    Егор, спасибо за статью. Мне было очень интересно прочитать про индексацию точек с помощью GiST, а также расширение gevel, так как ранее этими возможностями PostgreSQL мне пользоваться не доводилось.

    Касаемо полнотекстового поиска при помощи GIN и pg_trgm не могу не сообщить, что не так давно писал об этом у себя в блоге (раз и два), а также делал доклад на РИТ (слайды). Авось соответствующие материалы кого-то заинтересуют.
  • Современный CMake: 10 советов по улучшению скриптов сборки
    +1
    С вашего позволения, хотел бы добавить пару (возможно, спорных) советов от себя.

    1) Откройте для себя наконец Ninja (cmake -G Ninja ..). Скорость сборки возрастает существенно.
    2) По возможности распиливайте проект на библиотеки и тяните их через git submodules.
    3) Если тест можно написать на Python, пишите на Python.
    4) И вообще раз заговорили про C++: сразу прикручивайте clang-format, clang static analyzer, cppcheck и valgrind, мерьте степень покрытия кода с помощью lcov.

    У себя в бложике я описывал эти моменты более подробно.
  • Индексы в PostgreSQL — 3
    +3
    Amit Kapila не так давно показал, что хэш-индексы иногда могут быть быстрее B-деревьев. Следовательно, если вы ищите только по равенству, имеет смысл сравнить оба варианта и выбрать тот, который на ваших данных и объемах будет быстрее.
  • Pthreads: Потоки в русле POSIX
    +5
    Спасибо за статью. Стоит добавить, что pthreads также предлагает примитивы синхронизации, в частности мьютексы — см man pthread_mutex_init и далее по ссылкам.
  • Примеры реальных патчей в PostgreSQL: часть 3 из N
    0
    В соответствии с произношением — ˈbätl
  • Примеры реальных патчей в PostgreSQL: часть 3 из N
    0
    Ну, например:

    vim query.sql
    :!psql query.sql


    Просто первое, что в голову пришло.
  • Примеры реальных патчей в PostgreSQL: часть 3 из N
    +1
    Все через psql
  • Примеры реальных патчей в PostgreSQL: часть 3 из N
    0
    В настоящее время не пользуюсь никакими.

    Раньше пробовал разные. Советую посмотреть на DataGrip от JetBrains.
  • Еще одна новая фича pg_filedump: восстанавливаем каталог PostgreSQL
    0
    Ага )
  • Теория радиоволн: аналоговая модуляция
    0
    Большое спасибо за интересную серию статей.

    Не подскажете книгу или несколько хороших книг по этой теме?
  • Заметка о способе отладки блокировок в ядре Linux
    +1
    Спасибо, весьма познавательно. Пожалуйста, пишите еще статей о ядре Linux. Материалов решительно не хватает!
  • Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04
    –5
    Статья хорошая. С комментариями выше про Docker и Ansible не соглашусь, я бы лично просто завернул это в виртуалку, притом желательно VirtualBox, потому что он есть у всех.

    Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.
  • Пример восстановления таблиц PostgreSQL с помощью новой мега фичи pg_filedump
    0
    Ну как же она неизвестна? Вы же можете сделать тестовую инсталляцию и сказать \d, правда?
  • Python: коллекции, часть 2/4: индексирование, срезы, сортировка
    +1
    Хороший цикл статей. Читаю с удовольствием. Спасибо.
  • Уменьшение объема, занимаемого данными PostgreSQL на диске
    +3
    Я бы еще добавил к возможным подходам ZSON.

    В случае с текстовыми данными нужно учитывать, что в TOAST уже есть LZ-подобное сжатие, поэтому все большие объемы данных и так жмутся. На выравнивании можно выиграть еще 1-2 процента от силы.
  • Перехват системных вызовов Linux с помощью LSM
    0
    Последний раз когда я узнавал, книги были сильно устаревшими (была какая-то одна акутальная, но на немецком языке), а статьи быстро устаревали, потому что разработчики ядра не сильно парились по обратной совместимости внутри ядра. То есть чтобы быть в теме нужно постоянно чем-то около ядерным заниматься.
  • Перехват системных вызовов Linux с помощью LSM
    +13
    В высшей мере интересно, спасибо! Реквестирую больше статей о ядерной разработке в Linux.
  • Sharding – patterns and antipatterns
    0
    Обещанная статья: http://eax.me/sharding/
  • PVS-Studio для Linux
    0
    Ура-ура! Тестировал бету, был очень доволен. Вы молодцы!
  • Sharding – patterns and antipatterns
    0
    На счет терминов хочется подчернкнуть, что это не мое личное предложение. Это по мотивам терминологии, используемой в документации Couchbase, Cassandra, Riak, CockroachDB и других СУБД со встроенным шардингом/перебалансировкой.

    По поводу прикручивания транзакций сбоку позвольте не согласиться. Прикручиваются, хоть и не без осведомленности приложения или middleware через который приложение ходит в базу http://rystsov.info/2012/09/01/cas.html По-моему там в статье это не подчеркнуто, но чтобы получить настоящий snapshot isolation нужно при чтении ключей делать с ними то же самое, что и при записи. В документации к некоторым СУБД это называют 2PC транзакциями, но мне этот термин не нравится, так как к настоящему 2PC отношения не имеет.
  • Sharding – patterns and antipatterns
    +1
    Дисклеймер — написанное ниже очень субъективно и скорее всего придирки. И я понимаю, что целью доклада не являлось осветить это все. Тем не менее.

    Во-первых, существует некоторая путаница с терминологией. Каждая СУБД использует немного свои термины, но наиболее общий знаменатель примерно следующий. Под решардингом обычно понимают изменение числа бакетов/vnode. Например, если было hash(key) % 512, решили, что бакетов маловато, и перешли на hash(key) % 1024 или вообще на другую схему. Перенесение бакетов на другие физические машины обычно называют перебалансировкой. Как минимум, было бы не лишним предупредить, что такая путаница вообще есть. Вы же, как я понял, просто для всего решили использовать слово решардинг, тем самым, как мне кажется, оказывая слушателям медвежью услугу.

    Во-вторых, немного удивили повороты в стиле что прокси — это SPOF или что во время перебалансировки нода может упасть. Мне кажется само собой разумеющимся, что прокси должен быть не в одном экземпляре, и что «нода» это на самом деле мастер и пара реплик с фейловером (ручным или автоматическим).

    Наконец, да, полнота доклада. Что на самом деле интересно слушателям? Как им взять какой-нибудь Redis/Tarantool/PostgreSQL/MySQL/иную-систему-без-встроееного-шардинга и на базе нее построить что-то что масштабируется гаризонтально. Что для этого нужно? Да, действительно, какая-то схема шардирования, какой-то сервис дисковери (как получилось, что не вспомнили хотя бы ZooKeeper, не говоря уже про Consul или etcd? снова оказание медвежьей услуги — ведь слушатели побегут писать свое), процедура решардинга, процедура ребалансировки (важно подчеркнуть, что это отдельные вещи) и, самое интересное, транзакции между нодами.

    В сухом остатке. Вы подняли интересную тему, но не дали ответа на вопрос, который действительно всех интересует. Изложение явно не полное. В связи с чем отчасти даже вредное, а не полезное.

    Повторюсь, это все субъективная оценка. И я понимаю, что доклад, видимо, был ориентирован на новичков и делался, наверное, давно. Я постараюсь в ближайшем будущем написать свою версию того, как можно решить все описанные проблемы на примере PostgreSQL.
  • Sharding – patterns and antipatterns
    +2
    При всем моем глубоком уважении к докладчикам, доклад мне кажется слабоватым. Возможно, он просто ориентирован на начинающих.
  • Сравнение аналитических in-memory баз данных
    0
    Потрясающая статья, больше спасибо!

    Не могли бы вы рассказать, в чем именно заключаются преимущества развертывания PostgreSQL / Greenplum именно на XFS, а не на EXT4?
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Patches are welcome ;)
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Вижу вы послали патч в ЛС. Я его замержил, спасибо!
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Сейчас у zson_learn есть параметр, определяющий минимальное количество раз, которое строка должна встречаться в документах (по дэфолту 2, можно указать другое значение).
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Попробую, но заранее ничего не обещаю :)
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Не уверен, что понял ваш вопрос. Если вы хотите включить расширение для схемы, то насколько я знаю, это работать не будет.
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Если вы не обучаете zson и на тестовом окружении и на проде одновременно, то проблем быть не должно. Иначе перед обучением на тестовом окружении сначала перенесите полностью словарь с прода.

    И конечно же, на все всегда делайте бэкапы!
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Да как вам удобнее так и переносите. Через COPY например.
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Komzpa ну вы же знаете выражение — patches are welcome! :)
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Это, конечно же, просто косяк в тексте, имелся ввиду col. Исправил, спасибо!
  • ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
    0
    Никто еще не добавил :) В рассылке предлагают включить zson, расширенный для xml и text, в базовую поставку.