Интересный юридический прецедент был рассмотрен в немецком суде, который постановил, что веб-сайты со встроенными шрифтами Google нарушают Общий регламент ЕС по защите данных (GDPR).

Суд в Мюнхене обязал владельца веб-сайта выплатить 100 евро в качестве возмещения ущерба за передачу личных данных пользователя, а именно IP-адреса в Google через библиотеку шрифтов Google Fonts без согласия человека.

Google Fonts — это сервисная библиотека для встраивания шрифтов от Google, позволяющая разработчикам добавлять шрифты в свои приложения и веб-сайты для Android, просто ссылаясь на таблицу стилей. По состоянию на январь 2022 года Google Fonts представляет собой хранилище для 1358 семейств шрифтов.

По мнению суда несанкционированное раскрытие IP-адреса истца веб-сайтом, представляет собой нарушение прав пользователя на неприкосновенность частной жизни и что администратор ресурса теоретически может объединить собранную информацию с другими сторонними данными для идентификации лица, стоящего за этим IP. Как говорится в постановлении - истец утратил контроль над личными данными в пользу Google.

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

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

Не так давно подобной инцидент с Google уже имел место быть, когда Австрийский орган по защите данных постановил, что использование Google Analytics веб-сайтом NetDoktor, нарушает регламент GDPR, поскольку данные посетителей экспортируются на серверы Google в США, тем самым открывая двери для потенциальных клиентов и слежки со стороны ее спецслужб.

А так, казалось бы всего лишь шрифт.

корреляционные плеяды

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

== Мат Стат. построение корреляционных плеяд
https://youtu.be/tHZBU-q_Jxs
там впроцем на канале все 7 частей.

неплохая статья про РО и numpy

== Вычисление коэффициента корреляции Пирсона в Python с помощью Numpy
https://pythobyte.com/calculating-pearson-correlation-coefficient-in-python-with-numpy-c7357af3/

== Корреляционная матрица в Python – практическая реализация
https://pythobyte.com/correlation-matrix-in-python-34345/

== Корреляционный регрессионный анализ в Python
https://pythobyte.com/correlation-regression-analysis-in-python-edad6547/

годнота
ПРОСТО ВАУ. насколько же высокого уровня статья. прям оч шикарно

== GPS
https://ciechanow.ski/gps/

== Эксперимент Базермана: как мы ежедневно теряем деньги
https://habr.com/ru/post/596543/

Apache Avro для питона

https://avro.apache.org/docs/current/gettingstartedpython.html

и для пайдентик офкос
https://pypi.org/project/pydantic-avro/

== Решите уравнение ★ e^x=x^e
https://youtu.be/a1rdzQWGo-k

== Число e на пальцах
https://youtu.be/ha94GHrct24

второй способ даж и не знал. оч полезно
== Условная вероятность и формула Байеса. Задача про два кубика
https://youtu.be/0THgI47uqaA

Дедлоки (1/2)

Всех с наступившим! 🐌

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

Дедлок или deadly embrace, как их называл товарищ Дейкстра (тот самый, который алгоритм) — ситуация бесконечного ожидания, при которой группа процессов не может продолжать работу, пока «внешние силы» не совершат определенные действия. Слово «процесс» здесь не имеет отношения к процессам в операционной системе. Процесс в дедлоке — некий автомат с набором состояний. Такими состояниями могут быть «процесс А не владеет ресурсами» или «процесс B владеет ресурсом alpha и пытается получить ресурс beta». На самом деле определение не совсем корректное в 100% ситуаций, но для обсуждения большинства подходов подойдёт.

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

Такой дедлок называется либо ресурсным, либо interleaved дедлоком. Первое более привычное и популярное название, второе я нашёл только в [4]. Для возможности его возникновения необходимо выполнение 3 условий:

1. Exclusive access. Только один процесс может захватить ресурс одновременно.
2. No-preemption. Процесс, захвативший ресурс, не может быть прерван.
3. Hold and wait condition. Должны разрешаться ситуация, при которой процесс захватил сначала один ресурс, а теперь ждёт пока освободится второй. Не отпуская при этом первый.

Наличие этих условий в системе ещё не гарантирует возникновение дедлока! Это только необходимые условия. Их наличие означает существование unsafe region[5] — такого набора состояний процессов, попав в которое, ни один из процессов не может завершить свою работу.

При наличии unsafe region достаточно найти лишь 1 набор состояний, чтобы обеспечить дедлок. Оно же последнее условие:

4. circular wait condition. Процессы и ресурсы должны иметь возможность собираться в «цепочку». К примеру: Процесс A владеет ресурсом a при этом хочет захватить ресурс b, которым владеет процесс B, который хочет завладеть ресурсом a. Если обозначить эти отношения стрелочками:

a -> A значит процесс A владеет ресурсом a.
A -> b значит процесс A хочет завладеть ресурсом b.

Схематично получится круг (ну или квадрат):

a  -> A
^     |
|     v
B <-  b

Дедлоки (2/2)

Первый инсайт: дедлоки не возникают просто так, для них необходимо 3 условия: exclusive access, no-preemption, hold-and-wait + одно достаточное: circular wait.

Второй инсайт: чтобы побороть дедлок, достаточно избавить от одного из условий!

Пункт 2 особенно интересен, и позволяет другими глазами взглянуть на работу с ресурсами и привычные «программистские трюки». Например: почему часто разделяют локи на read-only и write-only локи? Для перформанса, конечно. Но ещё и потому что в read-only локе не может возникнуть дедлок, так как он не эксклюзивный (первое условие)!

Или вот я недавно сделал нечаянно не concurrent индекс в postgres на табличку с парой сотен миллионов записей и всё встало колом. Решение проблемы — preemption! Руками грохаем транзакцию и дедлок перестаёт существовать. И это магистры компьютерных наук знали ещё в 70-ых. Подобные же механизмы можно и автоматизировать. Правда не так просто. С одной стороны, обнаружение дедлока — в сущности задача на графах, где просто нужно правильно пройтись по ребрам от процессов до ресурсов. С другой, граф постоянно меняется буквально пока по нему проходишься. Кажется решений проблемы в общем случае нет, но в частных, например только в БД, они есть и работают.

С hold-and-wait тоже интересно. А что если бы процесс сразу же запрашивал все ресурсы, которые ему требуются? Или по крайней мере захватывал бы их постепенно, но при успехе отпускал бы все уже захваченные. Такой подход, оказывается, тоже убирает проблему дедлоков. К сожалению, не каждый процесс знает наперёд ни все нужные ему ресурсы, ни порядок, в котором они будут захватываться. Опять в общем случае решить тяжело, в частном вполне. Например обычно заранее известно, сколько памяти и CPU нужной новой виртуалке/контейнеру, а это тоже ресурсы, за которые тоже может быть конкуренция. Там правда ситуация не обязательно завершиться дедлоком, а скорее перемещением одного из процессов, но это детали. Раскидывать задачи по компьютерам — очень сложная задача, поэтому в как-нибудь в следующий раз.

Наконец, circular-wait. А пусть все ресурсы должны захватывать только в определенном порядке. К примеру, перечислим все ресурсы в системе от 1 до n. И добавим условие: если процесс захватил ресурс 1 <= k <= n, он может захватить только любой другой ресурс с номером m, где m < k. Другими словами, процессу сначала нужно захватить самый «высокоуровневый» ресурс, а дальше все ресурсы пониже. Наличие нумерованных ресурсов и одного условия на их захватывание также позволяет избавиться от дедлоков. Полный пруф есть в [5].

Все эти подходы можно широкими мазками разделить на 3 категории:

- Detection. Подходы, которые по графу ресурсов и их зависимостей позволяют обнаружить дедлок. Для борьбы используется preemption.
- Prevention. Цель: задизайнить систему таким образом, чтобы дедлок был невозможен. Например: пронумеровать ресурсы и ввести условие их захвата. Или запретить захватить ресурс, а затем ждать второй.
- Avoidance. Подходы, при которых система переходит только из одного «безопасного» состояния в другое. Решение о выдаче ресурса принимается динамически, к примеру во время запроса. Самый популярный алгоритм: алгоритм банкира. К сожалению для него необходимо, чтобы процессы сразу знали, какие ресурсы им нужны.
- Алгоритм страуса. Или ничего не делать. Стратегия при которой программист сажается на on-call и ему выдаётся кнопка «отмена».

Ресурсы:
1. E.G. Coffman, M. Elphick, A. Shoshani. System Deadlocks.
2. Richard C. Holt. Some deadlock properties of computer systems.
3. S.S. Isloor, T.A. Marsland. The Deadlock Problem: An Overview.
4. Gertrude Neuman Levine. Defining deadlocks.
5. Charles M. Shub. A Unified Treatment of Deadlock.

как всегда пишут... оставайтесь на уровне 3 и не ИИте мозги

Нормальные формы баз данных

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

00:00 Введение
01:20 Что такое нормализация
02:08 Что такое избыточность данных с примерами
04:51 Какие бывают нормальные формы БД
08:00 Ненормализованная форма
09:37 Первая нормальная форма
11:24 Вторая нормальная форма
15:29 Что такое декомпозиция
16:18 Третья нормальная форма
18:54 Нормальная форма Бойса-Кодда
21:54 Четвертая нормальная форма
27:45 Почему обычно не нормализуют до 5 или 6 формы
29:14 Пятая нормальная форма
35:39 Шестая нормальная форма
38:02 Выводы и заключение

Смотреть это видео на youtube: youtu.be/zqQxWdTpSIA

== SQL/JSON в PostgreSQL: настоящее и будущее
https://youtu.be/CPoNZRpcHf4

нахер монгу. хоронить её пора) а все с ней пытаются сравнивать