mayton2019

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

API позволяет взять ключ по имени.

Каждый хостинг-провайдер или платформа предоставляет такой сейф как услугу. Например для Microsoft
Azure Cloud это Key Vault. Для облака Амазон это AWS Secrets Manager.

Есть два подхода.

Нанести повреждения сырой файловой системе. Под суперпользователем открыть диск как блочное устройство
(файл по сути) и случайным образом внести изменения в случайные блоки (тут надо владеть информацией о размере блока) 512 байт или 4К или еще какие-то возможны варианты. Записать рандомный шум по сути. Только не трогай первый блок. Там может быть вайжная инфа о файловой системе. Иначе вообще не смонтируешь .. ну хотя может для тебя это тоже кейс.

Если изменение будет попадать в журналы - то они автоматом исправятся при старте. Насколько я помню ext4 хранит копии журналов в разных частях диска. Если изменения попадают внутрь тела файла то это мы не исправим никак. С точки зрения структуры ФС - все выглядит валидно. Структура - цела. Значит чекинг ничего не заметит.

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

UPD: Тут надо смотреть как собраны программные зеркала этой системы. Возможно исправить все таки можно но там будут куча условий. Целое дерево условие если это то это и так далее. Короче квест.

Вообще очень сильно зависит от цели задачи. И от чего мы пытаемся защититься. Если ты меняешь первый блок файловой.

Тоесть эксперимент похож на слепую стрельбу из пистолета в живого человека. Смотря куда попал. Если в башку - то смерть. Если там в мясо - то можно подлечить как-то.

Второй подход. Рассматривать обычный API файловой системы. Здесь можно просто проверить что будет когда inodes закончились. Ивестно что каждый файл (не hard-link) создает ровно 1 inode в таблице нодов. И эта таблица ограничена в ext3/ext4 кажется. Можно создавать миллионы файлов имеющих нулевой размер и мы постепенно заполним эту таблицу и получим какую-то ошибку. Эта ошибка технически имеет онлайн решение для XFS (там можно на ходу растягивать ФС и таблицы). Для ext3 нужно отмонтировать и что-то сделать в оффлайне.

Про коррапченые файлы мы уже говорили. Если это вопрос файловой системы - то она не видит ничего скорее всего. Рандомное изменение тела файла - это легальная операция файлового API. Увидит только софт который будет этот файл открывать. Например word документ не откроется. JPEG картинка может открыться наполовину. Будем видеть мозаику из поврежденных блоков начиная от места повреждения. Почти все файлы архивы перестануть распаковываться с места повреждения и до конца. Тоесть им
скорее всего смерть. Тестовые файлы - откроются но будем видеть "мусор" в месте повреждения.

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

Вот если бы ты реализовал 1/3 + 2/3 и получил бы точно единицу вот это было бы
интересно и познавательно.

Программирование в ООП предполагает что мир состоит из "объектов".
Например твоя программ (процесс) калькулятор это уже объект. Даже не имея декларации
она уже является объектом с точки зрения ОС.

Но если твой преподаватель - такой душный, то сделай

class Calculator {
   ...
}

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

Поясни это преподавателю если он будет сильно настаивать на том что мало объектов.

Вот тут есть десяток проектов релевантных к Эфирам и Питону
https://ethereum.org/ru/developers/docs/programmin...

В классических языках программирования происходит обнуление переменных int, long.
Тоесть ошибки не будет но счетчик пойдет снова с нуля. Чтоб детектировать - надо
делать проверку условия на максимум.

На уровне языка Ассемблер и процессора существует флаг переполнения (OF) который взводится в
состояние true если в результате сложения или инкремента последняя операция детектировала
переполнение. Тоесть обработать это технически возможность существует. И далее - условный переход
на обработку.

В реальных приложениях такого лучше не допускать. Лучше не жадничать и вводить long счетчики.
Их хватит на тысячи лет как-бы вы там интенсивно не делали инкременты. В базах данных типа Oracle
NUMBER тип хранит 38 десятичных знаков числа. Надолго хватает. И я не слыхал чтоб у кого-то в обычном
режиме бизнес-транзакций эти счетчики переполнялись.

У Постгреса была проблема с 32 битными счетчиками XID. Не знаю как они ее порешали. Кажется
как-то они сбрасывают их для всей таблицы. Толи в вакууме толи еще как-то я не помню. Пускай
постгресщики скажут точнее.

Чтобы уйти от мелких счетчиков попробуйте использовать SnowflakeId (64bit) или GUID(128bit). Их надолго
хватает и никто не жаловался. Git использует 160-bit идентификаторы коммитов в графе коммитов
и тоже пока никто не жаловался.

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

Если буквально переводить ошибку

In included file: unknown type name 'c_image'clang(unknown_typename)
window.hpp(24, 25): Error occurred here

То будет - во включаемом файле неизвестное имя типа c_image
и ошибка находится здесь window.hpp(24, 25)

Я устанавливал в таком порядке. Сначала windows а потом Linux. В этом случае у тебя есть возможность маневра. Если ставить наоборот то Windows убивал все что есть. Это было лет 10 назад. Как щас - не знаю. Может лучше.

Если тебе от ubuntu нужны только несколько утилит то попробуй под Windows использовать
WSL (Windows Substem for Linux). Обычно разработчикам и дата-инженерам этого достаточно
чтоб запускать какие-то утилиты или клиенты (azure(az), amazon(aws), gcp, databricks,
tools, converters, sql-clients e.t.c.)

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

Ничего не делай. Отнеси в ремонт пускай там сделают. Когда речь касается чего-то стоящего - лучше
не экспериментировать.

Важно, какие документы ты подписывал при приеме на стажировку или во время нее. Обычно
есть стандартная форма NDA, где пишут что ты не имеешь право распространять код который
относится к деятельности компании.

Свой личный код - можно но я тебе очень сильно не советую это делать с рабочей машины.
Миллион раз были случаи когда параметры user.name/user.email из конфигураций github
утекали в commit и по этим признакам очень легко было найти утечки. Причем я подозреваю
что у самого гитахба есть бигдата джобы которые сканят код на предмет бизнесовых торговых
марок и лейблов. Эти параметры можно менять и конфигурить для каждого проекта
но я все равно не советую. Имя пользователя ПК у меня некоднократно утекало почемуто
в MANIFEST.mf (так работал maven в дефолтной комплектации) и бог его знает сколько сюрпризов
вообще таят в себе современные компилляторы. Короче набей себе татуху на левой руке
"Never commit from Corporate Desktop! Never! You!"

Подобоный bash мониторинг может создавать ненужную нагрузку (например если ты ишешь через find)
а файлов очень много. Они мелкие и т.п. Вобщем если искать часто (каждые 5 минут - то это будет ненужная
нагрузка). А если искать редко - то какая польза в таком мониторинге?

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

Есть у меня мысль - поднять информацию не из файлового API (find/du/ncdu) а из таблиц inode.
Там как раз есть информация о размере. Оптимистично - это более быстрый метод. По крайней
мере факт превышения квоты будет виден. А вот кем - надо искать.

Еще есть мысль что контроль квот - это технология уходящего века. В мире современных файловых
систем никто давно уже не учитывает файлы. Создается толстое хранилище на базе zfs например.
Оно нарезается пользователям на кусочки по 16/32/64 Gb и отдаются в пользование. По ним-же
идет тарификация. Если пользователь захочет больше - на ходу ему растягивается кусочек до нужного
ему размера. Тариф соотв другой.

Диагностику протокола SSL/TLS можно сделать с помощью утилиты OpenSSL например
вот как тут пишут https://stackoverflow.com/questions/17742003/how-t...

Чтобы браузер полноценно работал с секретным протколом - ему нужен сертификат домена.
Я тут не уверен можно ли создать само-подписный сертификат для localhost но мои знакомые
девопсы хвастались что делали такое.

Для создания сертификатов полно инструкций.

JSON хорошо подходит для хранения неспецифицированных данных. Например у вас есть таблица товаров.
У товара есть базовые свойства такие как цена, категория, название и производитель.
А есть описалово товара где например для ТВ-панели будет около 50 параметров таких как диагональ,
яркость матрицы, и прочая техническая чепуха. Вот эти 50 параметров можно положить в JSON (или JSONB)
для Postgres. Потому что в магазине всегда есть прецензиозные клиенты которым нужна посудомойка розового цвета и встраиваемая и еще ценой такой-то и такой-то. Вот спецом для них такая структура может быть создана.

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

Мне кажется что флеш был уникален тем что сочетал в себе сразу 3 вещи. И среду разработки. И язык разработки. И плагин рендеринга векторной графики в браузере.

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

В прошлом были истинно программистиские решения такие как Java Applets но они не взлетели как раз
именно по причине того что были ориентированы на программиста а не на дизайнера. Дизайнеру
и в страшном сне не присниться писать java-код.

Если смотреть в сторону Unity то там вроде-бы можно сделать многое. Но там чорт-пойми какая лицензия
и создатели Unity закручивают гайки постоянно. А если ты - "вкатыш" в эту технологию то ты как-бы
интуитивно ищешь нечто свободное и либеральное к использованию. Желательно - opensource.