Дмитрий Беляев

Никак

Этот вопрос уже обсуждался стопицот раз. И всем обсуждателям я предлагаю небольшой кейс (после которого обычно становится понятно, почему никак)
Я - легитимный юзер, оплативший все услуги. У Вас нет оснований не показывать мне курс. Я подключаюсь и начинаю просмотр...
Где подвох, спросите Вы?
Правильно спросите. Потому что подключаюсь я с виртуалки, а параллельно ей, в абсолютно недостижимой для Вас области работает программа записи экрана. Которая в итоге сграбит все, что там игралось.
Как Вы собираетесь от этого защищаться?

Детект виртуалки - и отвалятся все, кто их использует
Какие-то фантастические варианты типа поляризационных очков - и курс купят полторы калеки

Никак.

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

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

Любой контент, отданный пользователю, может быть сграблен. Ни практически, ни теоретически этого избежать не получится. Даже не трать силы/время/деньги на достижение недостижимого.
Он может поставить камеру и снимать экран.
Он может подключить устройство по USB и гнать изображение параллельно на соседнее устройство, где происходит запись.
Ты можешь как угодно пытаться контролировать его компьютер, но он запустит браузер в виртуалке, а на хостовом компе - OSB studio и будет писать все, что творится в виртуалке.
В этой вселенной на текущем уровне технического развития это абсолютно невозможно. 100500%

У code review должна быть цель. В моей практике обычно проекты небольшие и там нет отдельных тестировщиков. Получается, что code review отвечает на три вопроса:

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

Получается что-то такое:

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

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

#!/bin/bash
DEBIAN_FRONTEND=noninteractive apt install mysql-server -y

str представляет собой неизменяемую последовательность байтов UTF-8 динамической длины где-то в памяти. Поскольку размер неизвестен, его можно обрабатывать только за указателем. Это означает, что str чаще всего используется как &str — ссылка на некоторые данные UTF-8, обычно называемые «срезом строки» или просто «срезом». Срез — это просто представление данных, и эти данные могут быть где угодно, например:

- В статическом хранилище: строковый литерал "foo"представляет собой файл &'static str. Данные жестко закодированы в исполняемый файл и загружаются в память при запуске программы.

- Внутри выделенной кучи: String разыменовывает представление &str в строке.

- На стеке: Например, в следующем примере создается массив байтов, выделенный стеком, а затем он получает представление этих данных как &str:

use std::str;

let x: &[u8] = &[b'a', b'b', b'c'];
let stack_str: &str = str::from_utf8(x).unwrap();

Используйте String, если вам требуется владение строковыми данными (например, передача строк в другие потоки или их создание во время выполнения), и используйте &str, если вам нужно только представление строки.

const cancelable = fn => { // Создаётся функция cancelable, которая принимает функцию и сохраняет в переменную fn
  const wrapper = (...args) =>{ // Создаётся функция-обёртка, которая принимает любой набор аргументов
    if(fn) return fn(...args) // Если в cancelable была передана функция, то вызывает её с необходимыми аргументами
  }

  wrapper.cancel = () => fn = null // Добавляет свойство во wrapper для очистки переменной fn 

  return wrapper // Возвращает обёртку
}

const fn = par =>{ // Функция, которая оборачивается в декоратор со своим аргументом
  console.log('Function called, par:',par)
}

const f = cancelable(fn) // Создаёт обёртку вокруг fn

f('first') // Function called, par: first
f.cancel() // fn является переменной внутри cancelable, здесь мы её обнуляем
f('second') // Ничего не выводит, потому что условие у wrapper отрабатывает, только если функция есть

ну логично что 11 поколение мощнее))) так что бери его

если жестко собрался к ядрам привязываться - тогда 10е...

и зачем на linux VB, когда там есть офигенный Qemu-KVM?)

от выбора библиотек

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

что значит код

ubfx r0, r0, #1, #1 -- извлечь битовое поле шириной 1 бит (правая единица) начиная с бита №1 (левая единица) из регистра r0 (правый r0) и поместить результат в r0 (левый r0).
bx lr -- перейти по адресу в регистре lr, обычно это возврат из подпрограммы.
Семантика опкодов легко гуглится по названию опкода и названию архитектуры процессора.

какая между ними разница

ubfx r0, r0, #1, #1
ubfx r0, r0, #2, #1
теперь, когда ты знаешь, что это за опкод, ты можешь понять сам, что они извлекают битовое поле начиная с разных битовых позиций.

что я делаю не так

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

не существует. иначе обфускация (минимизация - частный вид обфускации, хоть и с другими целями) не имела бы место быть.

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

Агрегация/Ассоциация/Композиция - это всё виды взаимоотношений между разными типами. Это не принципы
Абстракция - это просто сама возможность вводить какие-то новые абстракции, поверх уже существующих. Ради этого ООП и придумано.

ИМХО, вот эти все попытки выделить основные принципы ООП в современном мире не имеют смысла, тк языки сейчас мультипарадигменные и постоянно добавляют и убирают какие-то части.

И уже споров о глубинном смысле трёх волшебных слов была целая куча (а ведь если бы кто-то когда-то не решил всё уместить в одиночные слова - этой неразберихи бы не было)

Так что из всех принципов, которые объединяют все более-менее ООП-языки остаётся только:

1. Всё есть объект, и объект объединяет под собой некоторые данные (которые могут быть не доступны публично) и операции (методы или функции), которые можно произвести над совокупностью этих данных.
2. Имеется какой-нибудь механизм для полиморфизма.

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