Вкратце об уровнях сетевой модели OSI
(продолжение предыдущего поста)

🔌 Уровень 1 — Физический (Physical)

Передаёт необработанные биты по физическим каналам связи.
Протоколы: 10BASE‑T, DSL, ISDN, USB, RS‑232, SONET/SDH.
Устройства: кабели, концентраторы (hubs), повторители (repeaters).

🔗 Уровень 2 — Канальный (Data Link)

Обеспечивает передачу данных между узлами, MAC‑адресацию и формирование кадров.
Протоколы: Ethernet, PPP, STP, VLAN, LLDP.
Устройства: коммутаторы (switches), мосты (bridges).

🗺 Уровень 3 — Сетевой (Network)

Отвечает за маршрутизацию и логическую адресацию.
Протоколы: IPv4/IPv6, OSPF, EIGRP, RIP, MPLS, ICMP, NAT.
Устройства: маршрутизаторы (routers), коммутаторы L3 (L3 switches).

⚙️ Уровень 4 — Транспортный (Transport)

Гарантирует надёжную сквозную передачу данных.
Протоколы: TCP, UDP, SCTP, DCCP.
Ключевые элементы: порты, сегментация, управление потоком (flow control).

📊 Уровень 5 — Сеансовый (Session)

Устанавливает, поддерживает и завершает сеансы связи.
Протоколы: SIP, SMB, RPC, PPTP, TLS.
Ключевые элементы: аутентификация, управление сеансами.

🎛 Уровень 6 — Представительный (Presentation)

Форматирует и преобразует данные для приложений.
Функции: шифрование, сжатие, кодирование данных.
Примеры: шифрование SSL/TLS, JPEG, MP3, ASCII, JSON.

🎨 Уровень 7 — Прикладной (Application)

Предоставляет сервисы непосредственно пользовательским приложениям.
Протоколы: HTTP/S, DNS, DHCP, SSH, SMTP, FTP, SNMP.
Примеры использования: просмотр веб‑страниц, электронная почта, передача файлов.

Вопрос дня

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)

Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(продолжение предыдущего поста)

→ MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер.
→ Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила.

Компоненты

→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.

Поток данных (упрощённо)

→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь

Преимущества

→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.

Недостатки

→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).

Распространенные рекомендации по использованию

→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.

Глава Alphabet (Google) Сундар Пичаи сравнил вайб-кодинг с ростом популярности блогов и YouTube, но предупредил, что явление не должно затрагивать критически важные системы.

Гендиректор Google рассказал о резком росте числа вайб-кодеров, но предупредил, что продукт их работы не подходит для крупных кодовых баз, критически важных с точки зрения безопасности.

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

В то же время глава Google подчеркнул, что не применяет вайб-кодинг к обширным кодовым базам, «где действительно нужно сделать всё правильно».

https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html

Вкратце структура ядра Linux #linux

Известный исследователь в области искуственного интеллекта Ян Лекун (Yann LeCun) утверждает, что модели LLM сами по себе не являются пузырем ни в плане стоимости, ни в плане инвестиций — они будут способствовать развитию множества реальных приложений и оправдывать текущие расходы на инфраструктуру.

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

Линус Торвальдс и Линус Себастьян из Linus Tech Tips провели сборку идеального ПК для Linux

Для создания мощной рабочей системы Линусы выбрали:

- процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками;

- ОЗУ Kingston 16 ГБ DDR5 х4;

- видеокарту Intel Arc B580;

- материнскую плату GIGABYTE TRX50 AERO D;

- SSD-накопитель Samsung 9100 PRO 2TB;

- кулер Noctua NH-U14S TR5-SP6;

- блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium;

- системный блок Fractal Design Torrent E-ATX Case;

- 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR).

Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память).

https://youtu.be/mfv0V1SxbNA
https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/

Механизмы авторизации API
(продолжение к предыдущему посту)

Контроль разрешений пользователей в современных API

1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control)

→ Определение
✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель).

→ Как это работает
✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений.

→ Оптимально для
✓ Систем с чётко определёнными группами разрешений.
✓ Панелей управления, SaaS‑приложений, CMS‑платформ.

2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control)

→ Определение
✓ Принимает решения об авторизации на основе атрибутов.

→ Атрибуты включают
✓ Атрибуты пользователя (возраст, отдел, подписка).
✓ Атрибуты ресурса (тип, владелец).
✓ Атрибуты среды (время, местоположение).

→ Оптимально для
✓ Предприятий с сложными и динамическими правилами доступа.

3. Фреймворк авторизации OAuth 2.0

→ Определение
✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей.

→ Как это работает
✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен.

→ Распространённые потоки
✓ Код авторизации (Authorization Code).
✓ Учётные данные клиента (Client Credentials).
✓ Потолок для устройств (Device Flow).

→ Оптимально для
✓ Приложений, требующих входа через соцсети или безопасного делегированного доступа.

4. OpenID Connect (OIDC)

→ Определение
✓ Уровень идентификации, построенный на базе OAuth 2.0.
✓ Добавляет проверку личности пользователя с помощью ID‑токенов.

→ Что предоставляет
✓ Проверенную идентификацию.
✓ Единый вход (SSO, Single Sign‑On).
✓ Стандартные утверждения (имя, электронная почта и т. д.).

→ Оптимально для
✓ Систем аутентификации и авторизации.

5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token)

→ Определение
✓ Авторизация осуществляется с помощью подписанных JSON‑токенов.

→ Как это работает
✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом.

→ Преимущества
✓ Отсутствие состояния (stateless).
✓ Идеально для распределённых микросервисов.

→ Оптимально для
✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API.

6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control)

→ Определение
✓ Решения о доступе принимаются с использованием централизованных политик.

→ Как это работает
✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос.

→ Оптимально для
✓ Государственных систем.
✓ Среды с жёсткими требованиями соответствия.

7. Списки контроля доступа (ACL, Access Control Lists)

→ Определение
✓ Разрешения настраиваются непосредственно для каждого ресурса.

→ Как это работает
✓ Ресурс содержит список разрешённых пользователей и действий.

→ Оптимально для
✓ Файловых систем.
✓ Моделей безопасности на уровне ресурсов.

Краткое резюме

✓ RBAC → На основе ролей.
✓ ABAC → На основе атрибутов.
✓ OAuth 2.0 → Делегированный доступ.
✓ OIDC → Уровень идентификации.
✓ JWT → Без состояния, на основе токенов.
✓ PBAC → На основе политик.
✓ ACL → На уровне ресурсов.

Вкратце про математические деревья

Линус Торвальдс о резервном копировании данных:

«Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML
(Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it")

«Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips
(Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")

Стратегии работы с базами данных
(продолжение в следующем посте)

Стратегии работы с базами данных
(продолжение предыдущего поста)

1. Когда нагрузка на чтение и запись высокая (сбалансированная нагрузка):
* Используйте основную базу данных для всех операций записи.
* Передавайте интенсивный трафик чтения на несколько реплик для чтения через асинхронную репликацию.
* Применяйте кэш Redis для обработки «горячих» ключей и снижения нагрузки на базу данных.
* Учитывайте, что иногда могут возникать промахи кэша (cache miss) — в таких случаях обращение будет перенаправлено к основной базе данных.
* Группируйте операции записи и оптимизируйте индексы, чтобы поддерживать стабильную производительность.

2. Когда нагрузка на запись постоянно растёт:
* Разделите базу данных на шарды (сегменты).
* Каждый шард хранит часть набора данных, благодаря чему операции записи распределяются.
* Ваше приложение должно уметь направлять запросы к нужному шарду.
* Подходит для масштабного развёртывания, но может быть сложным при выполнении комплексных запросов или транзакций между шардами.

3. Когда требуется гибридная масштабируемость (NewSQL):
* Системы вроде CockroachDB работают как SQL, но масштабируются как NoSQL.
* Встроенные функции автоматического шардирования и перераспределения нагрузки избавляют от необходимости вручную управлять шардами.
* Обеспечивается глобальная согласованность данных между узлами.
* Подходит для мультирегиональных приложений, где важны строгая согласованность и отказоустойчивость.

4. Когда требуются операции с высокой степенью надёжности (финансовые операции):
* Система разрабатывается специально для эконом. операций, например, бухгалтерского учёта, платежей...
* Очень высокая скорость работы, устойчивость к сбоям и подход, основанный на формальной верификации.
* В первую очередь обеспечивается корректность — предотвращаются двойные списания, условия гонки и частичные записи.
* Идеально подходит для операций с деньгами, когда каждая транзакция должна быть точной, надёжной и безопасной.

Как двоичные данные транслируются в инструкции ассемблера

Обучение с помощью чат-ботов приводит к поверхностному усваиванию материалов

Исследователи Шири Мелумад и Джин Хо Юн в ходе нескольких экспериментов с участием более 10 тысяч человек выяснили, что обучение с помощью ChatGPT и других чат-ботов приводит к тому, что материал усваивается более поверхностно.

Участников просили изучить определённую тему — например, как вырастить огород. Потом их случайным образом направляли либо к ChatGPT, либо к обычному поиску в Google. Далее испытуемый должен был написать совет «другу», основываясь на полученных знаниях.

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

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

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

https://academic.oup.com/pnasnexus/article/4/10/pgaf316/8303888?login=false

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