== Pointers in C / C++ [Full Course]
https://youtu.be/zuegQmMdy8M

4 часа занятного забавного индусского говора про поинторы в Си. в 2х норм

Разжовывает до состояния питьегого пюре

- Introduction to pointers in C/C++
- Working with pointers
- Pointer types, pointer arithmetic, void pointers
- Pointers to Pointers in C/C++
- Pointers as function arguments - call by reference
- Pointers and arrays
- Arrays as function arguments
- Character arrays and pointers - part 1
- Character arrays and pointers - part 2
- Pointers and 2-D arrays
- Pointers and multidimensional arrays
- Pointers and dynamic memory - stack vs heap
- Dynamic memory allocation in C - malloc calloc realloc free
- Pointers as function returns in C/C++
- Function Pointers in C / C++
- Function pointers and callbacks
- Memory leak in C/C++

#программирование

Наткнулся на весьма интересный инструмент ускорения разработки. Это fig - autocomplete для терминала.

Можно ввести “docker r” и он продолжит “docker run”. Казалось бы всего две буквы, но если часто зависаете в терминале с докерами и файлами, то очень повышает эффективность.

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

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

#prog #rust #моё

Меня тут один Олег™ попросил коротко рассказать о афинных типах в Rust. Что ж, рассказываю.

Аффинные системы типов — это системы типов, в которых объявленные значения можно использовать не более одного раза. Как и прочие ти́повые навороты, это позволяет писать более корректные программы путём перекладывания бо́льшего числа проверок на компилятор.

Для демонстрации практической пользы приведу пару примеров из стандартной библиотеки Rust:

1. std::sync::Mutex. Для корректной работы многопоточной программы требуется, чтобы доступ к совместно разделяемым изменяемым данным был должным образом синхронизирован. Один из способов достичь его — это защитить изменяемое значение мьютексом. Простой способ, обладающий, однако, существенным недостатком: очень просто забыть захватить блокировку перед тем, как получить доступ к значению (особенно если мьютекс защищает несколько переменных). Какое решение предлагает Rust?

Посмотрим на то, как создать мьютекс. Единственный способ создать мьютекс — это передать ему защищаемое значение. После этого получить доступ к разделяемому значению можно, только попытавшись захватить блокировку или же разрушив мьютекс, причём последнее можно сделать только в том случае, если поток (в смысле thread) единолично владеет мьютексом. Таким образом, несинхронизированный доступ исключён.

Другая возможная проблема с мьютексом связана с тем, что в большинстве языков программирования значения неявно копируются: нужно прилагать специальные усилия для того, чтобы удостовериться, что каждый из thread-ов получает один и тот же мьютекс, а не свою собственную копию (тут была шутка про Go, но она была настолько толстой, что Telegram не давал загрузить пост). В Rust это получается автоматически: нет методов, позволяющих получить копию мьютекса, поэтому расшарить можно только тот или иной вид указателя на мьютекс.

2. std::fs::File. Сборщик мусора помогает освобождать занятую память, но он не очень помогает с внешними ресурсами, в частности, файлами: закрыть файл обычно нужно сразу после того, как работа с ним окончена, а сборщик мусора никаких гарантий по времени закрытий файла не даёт. В стандартной библиотеке большинства языков программирования (даже с GC) есть отдельная функция, которая закрывает файл. Тем не менее, присутствие этой функции обнажает серьёзный изъян в системе типов: файл невозможно использовать после закрытия (также, как и до открытия, но обычно это не является большой проблемой), но это состояние никак не отслеживается в системе типов. Более того, дважды закрывать файл может быть попросту опасно: например, на Linux файл описывается файловым дескриптором — фактически, просто числом. После закрытия файла это же числовое значение может быть переиспользованно для другого файла, поэтому второе закрытия того же файлового дескриптора может привести к закрытию файла в другой программе!

Как эти проблемы обходятся в Rust? Если вы проверите API File, то... Вы не найдёте там метода close! Когда File выходит из области видимости, для него вызывается деструктор, который и закрывает файл. Т. к. явного метода закрытия файла в публичном API нет, единственный способ форсировать закрытие файла — это дропнуть файл (например, вызовом std::mem::drop). В силу того, что после этого получить доступ к файлу нельзя, возможность двойного закрытия статически запрещается.

Очевидно, аффинные типы не являются серебряной пулей. Каковы же недостатки? Конкретно в случае с File недостаток очевиден: закрытие файла может завершиться ошибкой, но закрытие посредством вызова деструктора не позволяет об этом узнать. Более сильные линейные типы (в которых каждое значение используется ровно один раз) позволили бы решить эту проблему, требуя явно вызывать close и таким образом давать доступ к возможным ошибкам, но это уже тема для другого поста.

== Building Data Pipelines with Apache Kafka® and Confluent | Data Pipelines Tutorials

https://www.youtube.com/playlist?list=PLa7VYi0yPIH1MculjFWJxs-aENPxRHHOS

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

== СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ - 1997год

Unix:
- Структура ФС на диске
- Индексный дескриптор файла
- Монтируемость ФС
- Рабочие файлы
- Каталоги
- Специальные файлы (файлы устройств)
- права доступа
- Логическая структура ФС
- Внутрисистемная организация ввода/вывода
- Данные, ассоциированные с ОС и с процессом
- Взаимодействие с устройствами

Windows NT:
- Объектная модель и контроль доступа
- Организация ввода-вывода
- NTFS, принципы, восстанавливаемость


ААААА ВИнда, за что ты такая сложная а ????? переусложнили капец... и слои и клиент-серверы и микроядра и басы...

== Что такое файловый дескриптор простыми словами
https://timeweb.com/ru/community/articles/chto-takoe-faylovyy-deskriptor-prostymi-slovami

== Some obscure C features

https://multun.net/obscure-c-features.html

наконец добрался дослушать

== REST vs gRPC
https://youtu.be/jlzomoLBl6U

== REST vs GRPC (JSON index attachment)
ttps://youtu.be/jILVrU1w_yc

== Мнимые числа реальны: #1-13 [Welch Labs]
https://youtu.be/kicp_odjsRs

хехех... короч пошел ка я читать кернель как писать... надоели эти ваши сайтики и вебчики

== Rust takes a major step forward as Linux's second official language
https://www.zdnet.com/article/rust-takes-a-major-step-forward-as-linuxs-second-official-language/

== Rust support
https://lkml.org/lkml/2021/12/6/461

== Как работают коды Spotify?
https://habr.com/ru/company/ruvds/blog/594115/
https://boonepeter.github.io/posts/2020-11-10-spotify-codes/
- Упреждающая коррекция ошибо (FEC)
- Код Грея

== Spotify Codes - Part 2
https://boonepeter.github.io/posts/spotify-codes-part-2/
https://habr.com/ru/company/ruvds/blog/594623/
- CRC Calculation
- Convolutional encoding
- Convolutional decoding

== Комплексные и мнимые числа. Реальность Торвальда
https://youtu.be/RfQ0GgoLcks

== ОБЩАЯ АЛГЕБРА. Основные понятия и математическая красота
https://youtu.be/xvl9mYYBXC4

Финалисты конкурса AES.

(Конкурс по выбору нового алгоритма шифрования, для замены DES).

AES (англ. Advanced Encryption Standard) — симметричный алгоритм блочного шифрования (размер блока 128 бит, ключ 128/192/256 бит), принятый в качестве стандарта шифрования правительством США по результатам конкурса AES. Этот алгоритм хорошо проанализирован и сейчас широко используется. Но многие забывают про достойные альтернативы (Но не все, например, масштабно используются в Truecrypt/Veracrypt/Zulucrypt, и не только).

Twofish.

Симметричный алгоритм блочного шифрования с размером блока 128 бит и длиной ключа до 256 бит. Число раундов 16. Разработан группой специалистов во главе с Брюсом Шнайером. Являлся одним из пяти финалистов второго этапа конкурса AES. Алгоритм разработан на основе алгоритмов Blowfish, SAFER и Square.

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

Serpent.

Разработан Россом Андерсоном, Эли Бихамом и Ларсом Кнудсеном. Некоторые предыдущие разработки авторов тоже носили названия в честь животных, например Tiger, Bear.

Алгоритм являлся одним из финалистов 2-го этапа конкурса AES. Как и другие алгоритмы, участвовавшие в конкурсе AES, Serpent имеет размер блока 128 бит и возможные длины ключа 128, 192 или 256 бит. Алгоритм представляет собой 32-раундовую SP-сеть, работающую с блоком из четырёх 32-битных слов. Serpent был разработан так, что все операции могут быть выполнены параллельно, используя 32 1-битных «потока».

При разработке Serpent использовался более консервативный подход к безопасности, нежели у других финалистов AES, проектировщики шифра считали, что 16 раундов достаточно, чтобы противостоять известным видам криптоанализа, но увеличили число раундов до 32, чтобы алгоритм мог лучше противостоять ещё неизвестным методам криптоанализа.

Став финалистом конкурса AES, алгоритм Serpent в результате голосования занял 2 место.
Шифр Serpent не запатентован и является общественным достоянием.

Обсудить в чате 👉 https://news.1rj.ru/str/+jrxm2KHbIl9kMDQy

== Introducing Firefox’s new Site Isolation Security Architecture
https://hacks.mozilla.org/2021/05/introducing-firefox-new-site-isolation-security-architecture/

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

== Mechanical Sympathy
https://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html

единственный способ задать линеаризуемость на уровне хотя бы одного CPU

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

В двух словах, это очень большая нейронка, обученная на 170B слов, причем на корпусах из разных языков (включая русский).

Что она может:
- генерировать саммари по тексту
- писать развернутые тексты по ключевым фразам или эпилогу
- отвечать на вопросы (Q&A)
- даже вести диалог (чатбот)

Пока качество производимого текста очень неоднородно. Иногда получается интересно, иногда похоже на ерунду. Однако уже есть несколько стартапов, которые построены на основе GPT-3.

Но, самым известным (и интересным) проектом, основанным на GPT-3 является Github Copilot. Это когда просто описываешь желаему функциональность, а код пишет нейронка. Вот теперь есть желание попробовать как это работает. Записался в лист ожидания, когда получу доступ отпишусь что-как.

А пока можно зайти в playground (регистрация обязательна) для GPT-3 и поиграться с этой нейронкой.