В продолжение рубрики "конспект админа" хотелось бы разобраться в нюансах технологий ОЗУ современного железа: в регистровой памяти, рангах, банках памяти и прочем. Подробнее коснемся надежности хранения данных в памяти и тех технологий, которые несчетное число раз на дню избавляют администраторов от печалей BSOD.

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат.

После статьи ValdikSS о блокировке сайтов по тухлым доменам РКН мне не давала покоя мысль о том, что произойдёт, если реестр начнёт резолвится в очень большое число IPv4-адресов. Проводить полноценные "учения" мне кажется сомнительным делом, т.к. они могут случайно обернуться умышленным нарушением связности рунета. Поэтому я ограничился поиском ответов на два вопроса:

• добавляют ли провайдеры автоматически IPv4-адреса из DNS в таблицы маршрутизации?
• корректно ли обрабатывают подобные пополняющие RIB системы большие DNS-ответы, содержащие тысячи записей?

Я нагрепал и зарегистрировал несколько свободных доменов из списка, поднял DNS сервер и поставил писаться трафик в pcap...

На этот пост меня подтолкнула публикация «Почему я ворую книги, бедные авторы, и как это исправить», а именно — скепсис и возражения на мой комментарий о том, что я не читаю плохие книги. Мне предложили рассказать, как я выбираю книги для чтения и что именно читаю. Ну я и повелся.
Оформить список было сравнительно просто, FBReader любезно хранил на GoogleDrive все скачанные книги с того момента, как там появилась эта услуга. Предлагаю вашему вниманию список прочитанного мной за 2,5 года из жанров фентези и фантастики.

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

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

В предыдущей статье я описал основные проблемы подстерегающие администраторов в больших компаниях.

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

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

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Вводная

Мне часто в проектах приходится сталкиваться с фреймворками по работе с БД. Концептуально, эти фреймворки можно разбить на 2 больших класса:

• ORM-ориентированные
• SQL-ориентированные

Некоторые из них хороши, какие-то не очень. Но субъективно могу сказать: SQL-ориентированные уступают в развитии ORM-ориентированным. Подчеркну, в развитии, а не в возможностях. Хоть изменить эту чашу весов и не получится, но предложить необычный взгляд на мир SQL-ориентированного подхода — вполне. Кому интересно, добро пожаловать под кат

Очень короткая заметка из серии «Хозяйке на заметку».

Предисловие

У плохо организованных разработчиков, типа меня, часто так бывает, что накомитишь всякого, а потом оказывается что не то и не туда, но git помнит всё и весь этот разгул анархии остаётся в истории.
Мне всегда казалось что это можно исправить, но сколько раз я не начинал искать ответа на этот вопрос — как в git удалить камиты — столько раз мне это не удавалось.
А всё потому что мои поиски приводили меня к rebase, а надо было искать reset.
На мой вкус вопрос недостаточно освещён и моя заметка призвана закрыть этот пробел.

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

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

В 2017 году блокчейн стал предметом научного интереса, когда в Торонто открылся первый институт исследований блокчейна. Около 30 ведущих экспертов приступили к разработке различных проектов, связанных с этой технологией.



Блокчейн — это надёжный способ хранения данных о сделках, контрактах, транзакциях, обо всём, что необходимо записать и проверить. Сегодня блокчейн проник практически во все сферы жизнедеятельности, готов в корне изменить финансовую систему государства и в разы упростить работу среднего и крупного бизнеса. Блокчейн не секретная технология: в сети огромное количество статей о том, как он устроен и по какому принципу работает. Мы собрали самые интересные и нужные факты в одну статью, на которую можно давать ссылку, когда вас спросят: «Что же такое блокчейн?»

В предыдущей статье «Зачем нужно моделировать индивидуальные и типовые сценарии?» я рассказал про необходимость моделирования как типовых, так и индивидуальных сценариев в тех случаях, когда заказчик хочет автоматизировать три функции:

1. Моделирование операций и сценариев на основе типовых схем.
2. Сравнение полученных результатов с планируемыми.
3. Корректировка планов.

Теперь я сконцентрирую свое внимание на разнице в моделировании предстоящих работ и свершившихся действий.

tmux — это менеджер терминалов, к которому удобно подключаться и отключаться, не теряя при этом процессы и историю. Как screen, только лучше (в первую очередь потому, что использует модель клиент—сервер).



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

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

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

Под катом приводится краткое описание одного из самых известных генетических алгоритмов вещественной оптимизации — алгоритма дифференциальной эволюции (Differential Evolution, DE). Для сложных задач оптимизации функции n переменных этот алгоритм обладает настолько хорошими свойствами, что зачастую может рассматриваться как готовый «строительный блок» при решении многих задач идентификации и распознавания образов.

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

• Простота реализации
• Не требуется обратного распространения
• Легко масштабируется в распределенной среде вычислений
• Малое число гиперпараметров.

Доброго времени суток.
А знаете ли вы, что не все хеш таблицы одинаково полезны? Сейчас я расскажу вам историю, как одна плохая хеш таблица скушала всю производительность, и не поморщилась. И как исправление этой хеш таблицы ускорило код почти в 10 раз.
Конечно, согласно теме — в статье речь пойдет о Delphi, но даже если вы не Delphi разработчик, то все равно советую заглянуть под кат, а после прочтения статьи в исходный код хеш таблиц, которые вы используете. А Delphi разработчикам я советую вообще отказаться от стандартного TDictionary.

Всем привет! У всех нас есть данные, которые хочется держать под контролем. Мы не хотим потерять к ним доступ и не хотим, чтобы доступ был у кого-то ещё. Где хранить такие данные? Я считаю, что Sia может стать идеальным местом для этого и расскажу, почему.

Предисловие

Примерно 9 лет назад, когда в моем городе появились первые безлимитные тарифы (что-то вроде 128 кбит/сек за 500 руб.), я принял решение держать в квартире собственный «сервер» для решения различных задач. Одной из первых идей было поднятие зеркала для проекта FreeBSD.org. Проработало оно где-то 2 года. Далее в этом уже не было смысла, ввиду расширения каналов и других причин.

Помимо этого, сервер принимал на себя в разные периоды времени и другие задачи:

• Хранение резервный копий данных, документов и дистрибутивов;
• Закачка торрентов;
• Раздача торрентов по DLNA и SMB на различные устройства;
• VPN-клиент к провайдеру (был даже период, когда сервер держал два PPTP соединения через MPD – для работы локального трафика и медленного безлимита);
• VPN-сервер и подключение до офисного шлюза (канал до работы);
• Asterisk сервер для IP-телефонии (в дальнейшем в доме появились всякие SPA-3112, радио-трубки и т.д.);
• FTP-служба для получения данных с IP-камеры, для сброса бекапов с Mikrotik-ов скриптами;
• И т.д. и т.п.

Общая мысль – в руках был конструктор с кучей разноцветных деталей и большое желание прикрутить еще что-нибудь эдакое. В общем то обычная ситуация для большинства системных администраторов, знающих и любящих *nix-системы.

Полгода назад написал бандл ClosureTable для фреймворка Laravel 3. Поводом для написания стала вот эта замечательная презентация Билла Карвина о способах хранения и обработки иерархических данных в MySQL с использованием PHP.

Итак. Существует несколько шаблонов проектирования баз данных для хранения и обработки иерархических структур:

• Adjacency List («список смежности»)
• Materialized Path («материализованный путь»)
• Nested Sets («вложенные множества»)
• Closure Table («таблица связей»)

Совсем недавно по планете прокатились волны WannaCry и его клонов. А сама проблема шифровальщиков стоит перед системными администраторами уже более 10 лет. Рано или поздно – но все внедренные и реализованные меры по защите от шифровальщиков не помогают и все-таки находится пользователь, который открывает письмо, вложение и получает полный «букет». Также много «приятных и увлекательных» часов получает системный администратор.

И тут то все четко начинают понимать, что нужны резервные копии (много, разных, в разных местах). Т.е. правило 3-2-1, придуманное и описанное Peter-ом Krogh-ом, весьма желательно выполнять. Данная статья – пример, который помогает сделать реальным выполнение данного правила на «коленке» — без покупки дорогостоящего оборудования (в условиях жесткой экономии).