Введение

Очень часто, как и в точных науках (физика, химия), так и в прочих областях (экономика, социология, маркетинг и пр.) при работе с разного рода экспериментально полученными зависимостями одной величины (Y) от другой (X) возникает потребность описать полученные данные какой-нибудь математической функцией. Этот процесс часто называют экспрессией, аппроксимацией, приближением или фиттингом.

Наиболее часто для фиттинга данных используется линейная функция:

$$

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

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

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



Эту метафору будет проще понять, если провести аналогию с черной дырой: мы не знаем, что находится под ее горизонтом событий, и чтобы это узнать нам нужно придумать способ, как туда добраться. Нечто подобное существует в мире математики. Данное уравнение — это настоящая «формула» простого числа, но чтобы ею пользоваться, нам нужно придумать, как искать подходящие {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, w, v, x, y, z}.

Черная дыра и данное уравнение — это предельные состояния чего-то реального и абстрактного. И, если о первом существует достаточно догадок и представлений, то о втором, практически ничего не известно. Но, что если это действительно «математическая» черная дыра? Разве вам не интересно что может произойти, если мы попадем под горизонт?

Часть 1. Вступление
…
Часть 7. Ещё возможности C++
Часть 8. Именование
Часть 9. Комментарии
…



Все мы при написании кода пользуемся правилами оформления кода. Иногда изобретаются свои правила, в других случаях используются готовые стайлгайды. Хотя все C++ программисты читают на английском легче, чем на родном, приятнее иметь руководство на последнем.
Эта статья является переводом части руководства Google по стилю в C++ на русский язык.
Исходная статья (fork на github), обновляемый перевод.

Недавно я вернулся к анализу погрешностей чисел с плавающей запятой, чтобы усовершенствовать некоторые детали в следующей редакции книги Physically Based Rendering. Числа с плавающей запятой — интересная область вычислений, полная сюрпризов (хороших и плохих), а также хитрых трюков, позволяющих избавиться от неприятных неожиданностей.

В процессе работы я наткнулся на этот пост на StackOverflow, из которого узнал об изящном алгоритме точного вычисления $$.

Но прежде чем приступать к алгоритму, нужно понять, что же такого хитрого в выражении $$? Возьмём $$, $$, $$ и $$. (Это реальные значения, которые получились у меня во время запуска pbrt.) При 32-битных значениях float получаем: $$ и $$. Выполняем вычитание, и получаем $$. Но если выполнить вычисления с двойной точностью, а в конце преобразовать их во float, то получится $$. Что произошло?

Проблема в том, что значение каждого произведения может сильно выйти за нижнюю границу $$, где расстояние между представимыми значениями с плавающей запятой очень велико — 64. То есть при округлении $$ и $$ по отдельности до ближайшего представимого float, они превращаются в числа, кратные 64. В свою очередь, их разность будет кратной 64, и не останется никакой надежды, что она станет к $$ ближе, чем $$. В нашем случае результат оказался ещё дальше из-за того, как два произведения были округлены в $$. Мы напрямую столкнёмся со старым добрым катастрофическим сокращением¹.

Введение

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

В случае, если вы создаете свой собственный репозиторий GitHub или часто контрибьютите в репозиторий, вам необходимо знать, содержит ли ваш код какие-либо уязвимости. Уязвимости репозиториев в прошлом вызывали проблемы с безопасностью. Это было подчеркнуто тем фактом, что две из самых больших утечек данных за последнее время — Equifax и Heartbleed SSL Exploit — начались с уязвимостей с соответствующими компонентами с открытым кодом, которые могут быть использованы в будущем.

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

Не смотря на то, что в последнем публиковавшемся перечне уязвимостей OWASP Top 10 2017 CSRF атаки отнесены к разряду “Удалены, но не забыты”, мы решили, что не будет лишним еще раз напомнить о том, как защититься от CSRF атак, опираясь на те же правила, предоставляемые OWASP.

TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

Введение

«Ой, ерунда, ячейки памяти на современных SSD выйдут из строя через десятки лет обычного использования, не стоит об этом беспокоиться, и уж тем более переносить swap, виртуальные машины и папку профиля браузера на HDD» — типичный ответ на вопрос о надежности твердотельных накопителей c гарантированными ≈150 TBW. Если прикинуть, сколько типичное ПО может писать данных, то кажется, что 10-20 ГБ в сутки — уже большая цифра, пусть будет максимум 40 ГБ, куда уж больше. При таких цифрах ответ вполне разумен — нужно 10 лет, чтобы достичь гарантированных значений по количеству перезаписи ячеек, при 40 ГБ записанных данных ежедневно.
Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками несколько раз в день, что оборачивалось 30-секундными задержками в обслуживании записи.

После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
19.7 ТБ.
Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!

Перевод статьи «JavaFX Tutorial: Basic layouts» автора Vojtech Ruzicka.

Как организовать и разместить GUI компоненты в приложении JavaFX.

Это четвертая статья в серии о JavaFX. В предыдущей статье я описал, как использовать FXML и SceneBuilder для создания вашего пользовательского интерфейса. Теперь мы рассмотрим макеты.

Все посты в серии о JavaFX:

1. Учебник по JavaFX: начало работы
2. Учебник по JavaFX: Привет, мир!
3. Учебник по JavaFX: FXML и SceneBuilder
4. Учебник по JavaFX: основные макеты
5. Учебник по JavaFX: расширенные макеты
6. Учебник по JavaFX: CSS стилизация
7. JavaFX Weaver: интеграция JavaFX и Spring Boot приложения

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

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

Введение

Современные корпоративные системы фильтрации контента, от таких именитых производителей как Cisco, BlueCoat, FireEye имеют довольно много общего с более мощными их собратьями — DPI системами, которые усиленно внедряются на национальном уровне. Суть работы и тех и других в том, чтобы производить досмотр входящего и исходящего интернет трафика и, на основании черных/белых списков, принимать решение о запрете интернет-соединения. А так как и те, и другие в основах своей работы полагаются на схожие принципы, то и способы их обхода также будут иметь много общего.

Одной из технологий, позволяющей достаточно эффективно обходить как DPI, так и корпоративные системы, является технология домен-фронтинга. Ее суть состоит в том, что мы идем на заблокированный ресурс, прикрываясь другим, публичным доменом, с хорошей репутацией, который заведомо не будет блокирован ни одной системой, например google.com.

О данной технологии было написано уже достаточно много статей и приведено много примеров. Однако популярные и обсуждаемые в последнее время технологии DNS-over-HTTPS и encrypted-SNI, а также новая версия протокола TLS 1.3 дают возможность рассмотреть еще один вариант домен-фронтинга.

Перевод статьи «JavaFX Tutorial: FXML and SceneBuilder» автора Vojtech Ruzicka.

Как создать графический интерфейс с JavaFX, используя разметку FXML и SceneBuilder.

Все посты в серии о JavaFX:

1. Учебник по JavaFX: начало работы
2. Учебник по JavaFX: Hello world!
3. Учебник по JavaFX: FXML и SceneBuilder
4. Учебник по JavaFX: основные макеты
5. Учебник по JavaFX: расширенные макеты
6. Учебник по JavaFX: CSS стилизация
7. JavaFX Weaver: интеграция JavaFX и Spring Boot приложения

Добрый день, друзья. В преддверии старта курса «Web-разработчик на Python» традиционно делимся с вами полезным переводом.

---

Вы видите перед собой руководство, которое расскажет, как создать приложение-чат на Python, Django и React.

В отличие от других руководств, я не использую Python и Django для WebSocket-соединений. Несмотря на то, что это звучит круто с технической точки зрения, работает это довольно вяло и само по себе затратно, особенно, если у вас приличное количество пользователей. Такие языки, как C++, Go и Elixir намного лучше справляются с ядром чата.

Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На Хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Предыдущие темы:

• Криптографические протоколы: определения, запись, свойства, классификация, атаки
• Протоколы распространения ключей на симметричных шифрах

Если между Алисой и Бобом существует канал связи, недоступный для модификации злоумышленником (то есть когда применима модель только пассивного криптоаналитика), то даже без предварительного обмена секретными ключами или другой информацией можно воспользоваться идеями, использованными ранее в криптографии на открытых ключах. После описания RSA в 1978 году, в 1980 Ади Шамир предложил использовать криптосистемы, основанные на коммутативных операциях, для передачи информации без предварительного обмена секретными ключами. Если предположить, что передаваемой информацией является выработанный одной из сторон секретный сеансовый ключ, то в общем виде мы получаем следующий трёхпроходной протокол.

В статье опишу использование Spring Data.

Spring Data — дополнительный удобный механизм для взаимодействия с сущностями базы данных, организации их в репозитории, извлечение данных, изменение, в каких то случаях для этого будет достаточно объявить интерфейс и метод в нем, без имплементации.

Содержание:

1. Spring Repository
2. Методы запросов из имени метода
3. Конфигурация и настройка
4. Специальная обработка параметров
5. Пользовательские реализации для репозитория
6. Пользовательский Базовый Репозиторий
7. Методы запросов — Query

Изучение истории дисков — начало пути к пониманию принципов работы твердотельных накопителей. Первая часть нашего цикла статей «Введение в SSD» проведет экскурс в историю и позволит наглядно понять разницу между SSD и его ближайшим конкурентом — HDD.

Несмотря на обилие различных устройств для хранения информации, популярность HDD и SSD в наше время неоспорима. Разница между этими двумя видами накопителей для обывателя очевидна: SSD дороже и быстрее, а HDD дешевле и вместительнее.

Отдельное внимание следует обратить на единицу измерения вместимости накопителей: исторически сложилось, что десятичные приставки, такие как кило- и мега-, в контексте информационных технологий подразумевают как десятая и двадцатая степень двойки. Для исключения путаницы были введены двоичные приставки киби-, меби- и другие. Разница этих приставок становится заметной с увеличением объема: покупая диск на 240 гигабайт, вы можете сохранить на нём 223.5 гибибайта информации.

Вы легко отзываетесь на просьбу помочь? Вам не трудно сделать пару лишних задач? Вы молча переделываете не очень хорошую работу за коллегами или подчинёнными? Скорее всего, ваша рабочая нагрузка заставляет вас «перегреваться». 

Нередко в малом бизнесе мы занимаемся всем подряд, не замечая того: тестовый сервер будет перезапущен, о чём мы сами и сообщим в чате клиенту вместо инженера; баннер повесить — да погоди, у меня есть доступ к админке, готово; код аналитики — да давай я тебе Tag Manager повешу и покажу, как через него любые теги размещать; вот тут в выгрузке были подозрительные пики и провалы, я тебе сделал дополнительную детализацию… Особенно тяжело ситуация обстоит в компаниях, которые активно работают по заявкам клиентов, и каждый сотрудник берёт в работу самые разноплановые задачи. Как итог: усталость, выгорание, ошибки и завалы собственных невыполненных задач. Знакомо? Давайте искать причины и выходы под катом.

Secure Shell (SSH) — широко используемый протокол транспортного уровня для защиты соединений между клиентами и серверами. Это базовый протокол в нашей программе Teleport для защищённого доступа к инфраструктуре. Ниже относительно краткое описание рукопожатия, которое происходит перед установлением безопасного канала между клиентом и сервером и перед началом полного шифрования трафика.

Обмен версиями

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

Обмен ключами

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

Перевод статьи «JavaFX Tutorial: Hello world» автора Vojtech Ruzicka.

Как создать ваше первое приложение JavaFX.

Это второй пост в серии о JavaFX. Вы можете прочитать в первой статье о том, как настроить вашу среду для разработки JavaFx.

Все посты в серии о JavaFX:

1. Учебник по JavaFX: начало работы
2. Учебник по JavaFX: Привет, мир!
3. Учебник по JavaFX: FXML и SceneBuilder
4. Учебник по JavaFX: основные макеты
5. Учебник по JavaFX: расширенные макеты
6. Учебник по JavaFX: CSS стилизация
7. JavaFX Weaver: интеграция JavaFX и Spring Boot приложения

На данный момент LLVM стала уже очень популярной системой, которую многие активно используют для создания различных компиляторов, анализаторов и т.п. Уже написано большое количество полезных материалов по данной тематике, в том числе и на русском языке, что не может не радовать. Однако в большинстве случаев основной уклон в статьях сделан на frontend и middleend LLVM. Конечно, при описании полной схемы работы LLVM генерация машинного кода не обходится стороной, но в основном данной темы касаются вскользь, особенно в публикациях на русском языке. А при этом у LLVM достаточно гибкий и интересный механизм описания архитектур процессоров. Поэтому данный материал будет посвящен несколько обделенной вниманием утилите TableGen, входящей в состав LLVM.

Причина, по которой компилятору необходимо иметь информацию об архитектуре каждой из целевых платформ вполне очевидна. Естественно, у каждой модели процессора свой набор регистров, свои машинные инструкции и т.д. И компилятору нужно иметь всю необходимую информацию о них, чтобы быть в состоянии генерировать валидный и эффективный машинный код. Компилятор решает различные платформенно-зависимые задачи: производит распределение регистров и т.д. К тому же в бэкендах LLVM также проводятся оптимизации уже на машинном IR, который больше приближен к реальным инструкциям, или же на самих ассемблерных командах. В подобных оптимизациях нужно заменять и преобразовывать инструкции, соответственно вся информация о них должна быть доступна.