Всем привет!

В этот раз я расскажу не про использование Python или очередной трюк с CSS/HTML и, увы, не про то, как я 5 лет портировал Вангеры, а про один важный аспект написания расширений для замечательной СУБД PostgresSQL.

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

К таблицам из Си можно получить доступ через хорошо описанный но медленный SPI (Server Programming Interface), также есть очень сложный способ, через буферы, а я расскажу про компромиссный вариант. Под катом я постарался дать примеры кода с подробными пояснениями.

Всем бойцам РХБЗ (радиационной, химической и биологической защиты) не посрамившим честь своего ОЗК посвящается...

С интересом читая статьи коллеги gjf про самые интересные, самые страшные и самые нестрашные яды испытываю ностальгию :). Потому что любой правильный химик, начиная свой творческий путь в первую очередь интересуется либо ядами, либо взрывчатыми веществами, либо наркотиками. Вот не встречал людей, которых в химию бы привело что-то другое, честно. Правда с годами, если хобби становится профессией, вся информация как-то переосмысливается и упорядочивается, возникают совершенно иные приоритеты. Вот и теперь, читая упомянутые статьи я вспоминал свой бумажный блокнотик, в котором в том числе были и описания необычных ядов. Все течет, все изменяется, теперь в моем «рабочем» блокноте чаще встречаются «противоядия». Ибо человеком придуманы тысячи способов уничтожить жизнь и пока не придумано ни одного — ее создать. Сила — в равновесии, поэтому если на Хабре есть яды — должны быть и противоядия. Ну и проснулся ж во мне перманентно дремлющий сержант белорусского РХБЗ. Статья коротенькая, почти без воды, но может так оказаться, что жизненно важная (=«закладочная», FAQ по метанолу)! За противоядием — идем под кат.

Что бы ни сказали — не станем спорить
Что бы ни дарили — не станем верить
Егор Летов «Как листовка»

Думаю не стоит лишний раз говорить о нашумевшем сериале Чернобыль и эффективности такого «сериального» воздействия на массы. Особенно на массы, проживающие на территориях, показанных в фильме. Выход каждой новой серии сопровождается всплеском публикаций в FB. В каждой из которых горечь, страх, боль. Что в такой ситуации я могу сделать ("кто виноват и что делать?")? Могу только описать свой взгляд на терапию лучевых поражений. Спасибо родненькой кафедре химии высоких энергий и проф. Шадыро О.И., которые пестовали в своих лабораториях нас, непутевых фармацевтов-радиохимиков. Надеюсь своей статьей честь этой, легендарной некогда, кафедры я не опорочу.

Ну и пишу, пишу, потому что стали забывать… Пугающе быстро стали забывать. Сначала в аптеках исчез йодид калия (я уж не говорю про описываемые в статье антидоты), потом так же неотвратимо исчезли льготы у ликвидаторов, знания у людей и т.д. и т.п.

В общем, спасибо, сценаристы HBO, за то, что всколыхнули Память. Мой посильный вклад — под катом. Рейтинг доступных (и не очень) антидотов, способных сработать при радиационном выбросе. В закладки — класть строго ВСЕМ! И прочитал сам — перекинь другу.

И снова здравствуйте! Заголовок статьи говорит сам о себе. В преддверии старта курса «Data Engineer» предлагаем разобраться в том, кто же такие дата-инженеры. В статье очень много полезных ссылок. Приятного прочтения.



Простое руководство о том, как поймать волну Data Engineering и не дать ей затянуть вас в пучину.

Складывается впечатление, что в наши дни каждый хочет стать дата-саентистом (Data Scientist). Но как насчет Data Engineering (инжиниринга данных)? По сути, это своего рода гибрид дата-аналитика и дата-саентиста; дата-инженер обычно отвечает за управление рабочими процессами, конвейерами обработки и ETL-процессами. Ввиду важности этих функций, в настоящее время это очередной популярный профессиональный жаргонизм, который активно набирает обороты.

Высокая зарплата и огромный спрос — это лишь малая часть того, что делает эту работу чрезвычайно привлекательной! Если вы хотите пополнить ряды героев, никогда не поздно начать учиться. В этом посте я собрал всю необходимую информацию, чтобы помочь вам сделать первые шаги.

Итак, начнем!

В этой статье разберёмся, как реализовать поддержку страничной памяти в нашем ядре. Сначала изучим различные методы, чтобы фреймы физической таблицы страниц стали доступны ядру, и обсудим их преимущества и недостатки. Затем реализуем функцию преобразования адресов и функцию создания нового сопоставления.

Этот цикл статей опубликован выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи лежат в этой ветке.

Ещё одна статья о страничной организации памяти?
Если вы следите за этим циклом, то видели статью «Страничная память: продвинутый уровень» в конце января. Но меня раскритиковали за рекурсивные таблицы страниц. Поэтому решил переписать статью, применив иной подход для доступа к фреймам.

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

В своих заметках я постараюсь поделиться не только исходными текстами (их можно найти на GitLab) и голой теорией (ее можно найти на многих ресурсах), но и тем путем, который я прошел, чтобы найти неочевидные ответы. Конкретно в этой статье я расскажу о компоновке файла ядра, его загрузке и инициализации.

Мои цели — структурировать информацию у себя в голове, а так же помочь тем, кто идет похожим путем. Я понимаю, что аналогичные материалы и блоги уже есть в сети, но чтобы прийти к моему текущему положению, мне пришлось долго собирать их воедино. Всеми источниками (во всяком случае, которые вспомню), я поделюсь прямо сейчас.

Итак, сразу к делу. Писать будем под Linux, на NASM и с использованием QEMU. Установить это легко, так что пропустим этот шаг.

Подразумевается, что читатель знаком с синтаксисом NASM хотя бы на базовом уровне (впрочем, ничего особо сложного здесь не будет) и понимает, что такое регистры.

Меня зовут Владислав, я участвую в разработке Tarantool — СУБД и сервера приложений в одном флаконе. И сегодня расскажу вам, как мы реализовали горизонтальное масштабирование в Tarantool при помощи модуля VShard.

^{Гора Пику образовалась очень задолго до прихода колонистов, ещё когда ломалась геологическая плита на Азорах. Высота Эвереста 8848 метров. А Пику — 8449 метров. Из которых 2351 метр приходятся на надводную часть, а остальное — гора под водой. То есть люди уже живут на склоне где-то в районе верхушки.}

Представьте, что вы португальский колонист. Вам достался совершенно офигенный остров, состоящий почти полностью из базальта. И совсем немного — из почвы. Куда ни ткнись, везде атмосфера, напоминающая замок «Инферно» из Героев. Если просто стоять на берегу, скоро на зубах начнёт скрипеть от базальтовой и туфовой крошки. Потому что остров образовался всего 60-70 тысяч лет назад.

Думаете, надо отчалить в ужасе и строиться на другом острове? А вот хрен там, вы не просто колонист, а вполне конкретный мужик, который потерял друзей, лодку и вообще чудом выплыл к этому гостеприимному берегу.

Потом вы живёте тут год и успеваете построить дом из окаменелой лавы. Посадить немного растений (на земле, которую вы очистили от лавы) и сделать себе новую лодку. Но не из лавы, а из дерева.

А потом вы вдруг понимаете, какое это крутое место. И вот на вечеринку приплыл неизвестный капитан, осмотрелся, и решил, что раз вы выжили, то выживут и остальные. И так появилось первое поселение.

В этой статье представляем страницы, очень распространённую схему управления памятью, которую мы тоже применим в нашей ОС. Статья объясняет, почему необходима изоляция памяти, как работает сегментация, что такое виртуальная память и как страницы решают проблему фрагментации. Также исследуем схему многоуровневых таблиц страниц в архитектуре x86_64.

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий запрос.

На разных конференциях обязанности участников программного комитета отличаются. Бывает так, что «программный комитет» и «организаторы» — в точности одни и те же люди, и каждый из них и швец, и жнец, и на дуде игрец. Тогда в круг их обязанностей внезапно попадает и выбор площадки, и аренда оборудования, и закупка еды, и маркетинг. Это очень интересные темы, но я не разбираюсь ни в одной из них. Поэтому сегодня мы сосредоточимся на том, что у программного комитета отнять невозможно: на работе с докладчиками.

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

Я говорю о работе с нормальными людьми, профессионалами в своём деле, а не в выступлениях. О работе с теми, кто сам подаёт заявку на доклад через форму подачи заявок. О работе с теми, кто на самом деле обеспечивает конференциям приток свежей крови и новых знаний, без которых весь процесс очень быстро выродится.

От загрузчика к ядру

Если вы читали предыдущие статьи, то знаете о моём новом увлечении низкоуровневым программированием. Я написал несколько статей о программировании на ассемблере для x86_64 Linux и в то же время начал погружаться в исходный код ядра Linux.

Мне очень интересно разобраться, как работают низкоуровневые штуки: как программы запускаются на моём компьютере, как они расположены в памяти, как ядро управляет процессами и памятью, как работает сетевой стек на низком уровне и многое другое. Итак, я решил написать еще одну серию статей о ядре Linux для архитектуры x86_64.

Обратите внимание, что я не профессиональный разработчик ядра и не пишу код ядра на работе. Это всего лишь хобби. Мне просто нравятся низкоуровневые вещи и интересно в них копаться. Поэтому если заметите какую-то путаницу или появилятся вопросы/замечания, свяжитесь со мной в твиттере, по почте или просто создайте тикет. Буду благодарен.

Софту мы не доверяем уже давно, и поэтому осуществляем его аудит, проводим обратную инженерию, прогоняем в пошаговом режиме, запускаем в песочнице. Что же насчёт процессора, на котором выполняется наш софт? – Мы слепо и беззаветно доверяем этому маленькому кусочку кремния. Однако современное железо имеет те же самые проблемы, что и софт: секретную недокументированную функциональность, ошибки, уязвимости, малварь, трояны, руткиты, бэкдоры.

ISA (Instruction Set Architecture) x86 – одна из самых долгих непрерывно изменяющихся «архитектур набора команд» в истории. Начиная с дизайна 8086, разработанного в 1976 году, ISA претерпевает постоянные изменения и обновления; сохраняя при этом обратную совместимость и поддержку исходной спецификации. За 40 лет своего взросления, архитектура ISA обросла и продолжает обрастать множеством новых режимов и наборов инструкций, каждый из которых добавляет к предшествующему дизайну, и без того перегруженному, новый слой. Из-за политики полной обратной совместимости, в современных процессорах x86 присутствуют даже те инструкции и режимы, которые на сегодняшний день уже преданы полному забвению. В результате мы имеем архитектуру процессора, которая представляет собой сложно переплетающийся лабиринт новых и антикварных технологий. Такая чрезвычайно сложная среда – порождает множество проблем с кибербезопасностью процессора. Поэтому процессоры x86 не могут претендовать на роль доверенного корня критической киберинфраструктуры.

В комментариях к предыдущему посту про иероглифы сказали, что хорошо бы иметь такую же блок-схему для кракозябр.

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Год назад мы добавили в наш агент сбор метрик из S.M.A.R.T. атрибутов дисков на серверах клиентов. В тот момент мы не стали добавлять их в интерфейс и показывать клиентам. Дело в том, что метрики мы снимаем не через через smartctl, а дергаем ioctl прямо из кода, чтобы этот функционал работал без установки smartmontools на серверы клиентов.
Агент снимает не все доступные атрибуты, а только самые значимые на наш взгляд и наименее вендор-специфичные (иначе пришлось бы поддерживать базу дисков, аналогичную smartmontools).
Сейчас наконец дошли руки до того, чтобы проверить, что мы там наснимали. А начать было решено с атрибута "media wearout indicator", который показывает в процентах оставшийся ресурс записи SSD. Под катом несколько историй в картинках о том, как расходуется этот ресурс в реальной жизни на серверах.

Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич PostgreSQL и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации.

Алексей Лесовский (@lesovsky) на Highload++ 2017 рассказал, как с помощью встроенных и сторонних инструментов, диагностировать различные типы проблем и как устранять их. Под катом расшифровка этого доклада, построенного по спиральному принципу: сначала мы перечислим все возможные средства диагностики, потом перейдем к перечислению типовых проблем и их диагностике, далее посмотрим, какие экстренные меры можно принять, и наконец как радикально справиться с задачей.


О спикере: Алексей Лесовский администратор баз данных в компании Data Egret. Одной из любимых тем Алексея в PostgreSQL является потоковая репликация и работа со статистикой, поэтому доклад на Highload++ 2017 был посвящен тому, как помощью статистики искать проблемы, и какие использовать методы для их устранения.

План

1. Немного теории, или как работает репликация в PostgreSQL
2. Troubleshooting tools или что есть у PostgreSQL и сообщества
3. Troubleshooting cases:
   
   • проблемы: их симптомы и диагностика
   • решения
   • меры, которые нужно принимать, чтобы этих проблем не возникало.

Зачем всё это? Эта статья поможет вам лучше разбираться в потоковой репликации, научиться быстро находить и устранять проблемы, чтобы сократить время реакции на неприятные инциденты.

Я много летаю и повидала разное дерьмо вроде восьмичасовой задержки рейса и больших окон между транзитами в 3 пересадки. Мои друзья теряли документы, или же мы просто летали через Копенгаген летом, когда койка в хостеле стоит 15 тысяч рублей за ночь.

Мы спали в Копенгагене в аэропорту, и было страшно. Как вернулись, я узнала про этот вид хобби много интересного.

Первое — идём на sleepinginairports.net. Там огромная база знаний, есть куча гайдов из серии «В этом аэропорту будьте внимательны, там нет розеток» или «Там есть зона A, где лучше всего спать». Там же показано, где душ, где можно вымыть ноги (в молельнях) и где комната йоги. Комната йоги — это сразу лютый вин, там очень хорошо спать.

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

18 мая 2018 года в Digital October состоится DevConf 2018. И мы решили пересказать некоторые интересные доклады с прошлогодней конференции. Там был доклад с несколько холиварным заголовком: "О чём молчит политрук: к дискуссии о переходе Uber с PostgreSQL на MySQL". В нем разработчик MySQL Алексей Копытов рассмотрел различия InnoDb и PostgreSQL на самом низком уровне, включая организацию данных, памяти и репликаций. Предлагаем вашему вниманию краткий пересказ доклада.

История вопроса

Uber перешел с MySQL на Postgres в 2013 году и причины, которые они перечисляют, были во-первых: PostGIS — это геоинформационное расширение для PostgreSQL и хайп. То есть, у PostgreSQL есть некий ореол серьезный, солидная СУБД, совершенный, без недостатков. По крайней мере, если сравнивать с MySQL. Они мало что знали о PostgreSQL, но повелись на весь этот хайп и перешли, а через 3 года пришлось переезжать обратно. И основные причины, если просуммировать их доклад — это плохие эксплуатационные характеристики при эксплуатации в production.

Deleted Deleted