#DevOPS #Other

NAS-хранилище (Network Attached Storage) — это отдельное устройство, чаще всего коробка с несколькими жёсткими дисками, которая подключается к сети и становится твоим личным сервером для хранения данных.

По сути это облако у тебя дома или в офисе.

Зачем вообще нужен NAS?

1. Хранение файлов в одном месте.

У тебя больше нет кучи флешек и «папки с фотками» на трёх разных компьютерах. Всё складывается на NAS, а доступ есть с любого устройства в сети (и даже через интернет).

2. Бэкапы и безопасность.

NAS поддерживает RAID-массивы, то есть может автоматически дублировать данные на разные диски. Один диск сгорел? Ну и похер, информация останется на другом. Это защита от «ой, у меня полетел жёсткий».

3. Совместная работа.

В офисе NAS работает как общий файловый сервер: каждый подключается и берёт нужные документы. Дома семья заливает туда фото, видео, музыку. Никаких «скинь мне по почте» или «передай через флешку».

4. Мультимедиа-сервер.

Многие NAS могут работать как медиацентр. Например, Plex или встроенные приложения превращают его в «домашний Netflix». Запускаешь фильм с NAS на телике и всё работает без танцев с бубном.

5. Свой облачный сервис.

Хочешь что-то вроде Google Drive, но без подписок и ограничения по размеру? Настраиваешь доступ через интернет и твой NAS превращается в личное облако.

6. Гибкость.

На современных NAS можно запускать приложения: от торрент-клиентов до Docker-контейнеров. По сути это уже мини-сервер.

А какие минусы?

Стоимость: хороший NAS + диски обойдутся дороже подписки на облако.

Нужно уметь хотя бы немного настраивать сеть.

Если сломался NAS (а такое бывает), придётся разбираться с восстановлением данных.

В сухом остатке

NAS это про контроль. Ты сам решаешь, где хранятся твои файлы и кто к ним имеет доступ. Для дома это удобно чтобы не потерять фотки и видео. Для бизнеса — не зависеть от сторонних сервисов.

Ну и конечно, это круто звучит: «А у меня свой сервер». Даже если он стоит рядом с роутером и тихонько гудит, пока ты смотришь сериальчики.

Все кто годами только сосали из меня энергию — специально для вас: больше никаких «помоги с экзаменом», «спаси меня»...
Я не донор.

Я трачу силы только на себя, код, работу и на тех, кто реально рядом.
Остальные? ПРОШУ НАХУЙ С ПЛЯЖА БЛЯДИ.

И знаете что? Легче дышать стало.

#Programming

Что такое «Тьюринг-полный язык»?

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

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

Какие критерии?

Чтобы язык был Тьюринг-полным, в нём должны быть:

1. Условные переходы (ветвления if/else или их аналоги).

2. Циклы или рекурсия (возможность перейти к метке как, допустим, go to).

3. Работа с памятью (хранить и изменять данные).

Если всё это есть, то значит язык может в теории решить любую задачу, которую можно сделать на компьютере.

Примеры

Python, Java, C, C++ — конечно, Тьюринг-полные.

SQL (чистый) — спорный случай. Но многие его реализации с процедурами и циклами становятся Тьюринг-полными.
Даже экзотика вроде Brainfuck или Minecraft Redstone (механизмов на основе функциональных блоков) при определённых условиях считаются Тьюринг-полными.

А зачем это знать?

На практике почти незачем. Потому что почти все современные языки уже Тьюринг-полные. Но само понятие полезно:

оно помогает понять границы того, что вообще возможно в вычислениях;

показывает, что ограничение чаще не в языке, а в разработчике (или его железа).

Итог

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

Потому что, да, и на Brainfuck можно написать «Змейку», но зачем мучиться если есть Python?

#ItLife

Иногда кажется, что отключить себя от IT это не про кнопки и выключатели, а про саму привычку жить внутри системы. Мы же прячемся туда не только ради работы, но и ради ощущения контроля. В любой ЭВМ всё чётко: если есть ошибка, то она где-то в коде; если что-то сломалось — вероятно это можно починить. В жизни так не работает.

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

Но человек ведь не может быть только процессором. У нас есть тело, которое требует банальных вещей: солнца, движения, касания. Есть сознание, которому нужно чуть больше чем сообщения в Telegram или таблицы в Excel. И когда мы слишком глубоко уходим в технологии, то по не многу теряем контакт с этим «живым» слоем.

Отключение от IT не про бегство от технологий, а напоминание себе что реальность не сводится к экрану. Что ценность не в том, сколько строк кода ты написал, а в том, как ТЫ проживаешь свой день.

Мы создали компьютеры чтобы они служили нам, а не наоборот.

#ItSecurity

Что будет с шифрованием в будущем?

Мы привыкли думать что криптография это что-то вечное: зашифровал и всё в безопасности. Но у каждого алгоритма есть свой «срок годности» и потенциально они скоро все сломаются.

1. Симметричное шифрование (AES, DES, ChaCha20)

Суть проста: один ключ и для шифрования, и для расшифровки.

Сейчас AES-256 считается золотым стандартом. Сломать его перебором нереально — нужно больше времени, чем существует вселенная.

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

Будущее: симметричные алгоритмы никуда не исчезнут, т.к. они быстрые и надёжные. Но их роль всё больше и больше будет связана с гибридными схемами (например, симметрия + асимметрия).

2. Асимметричное шифрование (RSA, ECC)

Здесь два ключа: публичный и приватный. Удобно для обмена и цифровых подписей.

RSA когда-то был непоколебимым, но рост вычислительных мощностей уже делает его уязвимым (2048 бит ещё ок, но меньше уже не вариант).

Эллиптические кривые (ECC) дают ту же безопасность при меньших размерах ключей. Сейчас это активно используется в TLS, криптовалюте и т. д.

Будущее: RSA постепенно уйдёт в архив, ECC останется в ходу, пока не придут квантовые компьютеры.

3. Хэш-функции (SHA-2, SHA-3, BLAKE2)

Хэш это не шифрование, а «отпечаток данных». Используется для проверки целостности и паролей.

Коллизии — главный враг (когда разные данные дают одинаковый хэш). MD5 и SHA-1 уже сданы на металлолом. SHA-2 и SHA-3 пока держатся.

Будущее: хэширование будет жить дольше всех. Даже квантовые компьютеры ломают их не так легко, как RSA.

Квантовая угроза

Пока её нет, но она стремительно надвигается. Алгоритм Шора (link1, link2) теоретически ломает RSA и ECC. Это значит, что всё что мы шифруем сегодня «надолго», завтра может оказаться прозрачным.

Будущее здесь уже формируется:

разрабатываются постквантовые алгоритмы (NIST сейчас как раз выбирает финалистов);

часть из них основана на решении задач, которые сложны даже для квантов (например, на решётках).

Итого:

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

RSA доживает последние годы как стандарт.

ECC будет в ходу, но с горизонтом «до квантов».

Хэшиотносительно безопасны, но постепенно будут меняться на новые стандарты.

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

А когда «кванты» станут реальностью — придётся пересматривать всю криптографию с нуля.

Кто прошел и написал 95% кода для хакатона? Кто сражался с командами по 5 человек в состоянии мертвеца?

Правильно — @Ximelay_y

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

#Programming

REST, gRPC и GraphQL: три способа разговаривать с сервером

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

Вот тут и начинаются халевары: REST, gRPC или GraphQL?
Каждый из них решает одну и ту же задачу — как клиент будет получать данные от сервера.

REST: старый, но надёжный

REST появился раньше всех и до сих пор живее многих «модных» технологий.
Он строится на простых принципах HTTP-ресурсов, методов GET, POST, PUT, DELETE, статусов ответов (200, 404, 500).

Всё что тебе нужно — это URL, например /users/1, и сервер. Последний ответит тебе JSON-ом:

{ "id": 1, "name": "Alex" }

REST хорош, когда:

тебе нужен простой API без лишней логики;

клиенты разные — от браузеров до мобильных приложений, а также curl;

важна стабильность и совместимость.

Почти все публичные API (Discord, GitHub, Telegram) испольуют REST, так как он универсален, понятен и предсказуем.

Минусы тоже есть:

для получения связанных данных (например, user + его посты) приходится делать несколько запросов;

из-за JSON и HTTP-заголовков передаётся много «воздуха»;

строгой схемы нет — всё можно поломать случайно.

gRPC: быстрый и умный

gRPC придумали в Google, когда REST перестал справляться с микросервисами.
Он работает на HTTP/2 и использует Protocol Buffers — формат бинарных данных.
Это значит: меньше байтов, больше скорости.

Вместо ручной сериализации JSON ты описываешь структуру в .proto файле:

message User {
  int32 id = 1;
  string name = 2;
}

И всё — система сама генерирует код под нужный язык (Go, Java, Python).

Плюсы gRPC:

очень быстрый, особенно на больших потоках данных;

поддерживает стриминг — сервер и клиент могут обмениваться сообщениями в реальном времени;

строгая типизация, меньше ошибок.

Минусы:

сложнее тестировать и смотреть ответы потому что вся информация находится в двоичном виде;

полноценно gRPC в браузере не работает, поэтому вротендерам нужен прокси;

требует внимательности при версионировании схем.

GraphQL: гибкость и контроль

GraphQL появился из другой боли — фронтендерам надоело запрашивать слишком много или слишком мало данных.

В REST ты получаешь всё что сервер решил отдать. В GraphQL ты сам говоришь:
«дай мне только имя и email вот этого пользователя».
И сервер возвращает ровно это, ничего лишнего.

{
  user(id: 1) {
    name
    email
  }
}

GraphQL работает поверх HTTP, но у него свой язык запросов.
Есть только одно подключение (endpoint), через которое идут все запросы.

Плюсы:

меньше запросов — можно собрать все данные за один;

гибкость на стороне клиента;

хорошая документация и автогенерация схем.

Минусы:

сложнее кэшировать;

если запросы составлены неаккуратно, то серверу может стать ОЧЕНЬ плохо;

требует продуманной архитектуры.

Где что использовать

REST: публичные API, простые интеграции JSON / HTTP.

gRPC: микросервисы, внутренние системы Binary (ProtoBuf).

GraphQL: клиентские приложения (веб, мобильные) JSON / HTTP.

Идеальной технологии нет.
Есть правильный выбор под задачу.

#OS #Windows #Linux

Microsoft сделала лучшую рекламу Linux, сама того не хотя

14 октября 2025 года — дата, которую Microsoft назвала «концом поддержки Windows 10».
По сути это «ваш компьютер больше не под защитой, покупайте новый или платите нам».

И ведь 10-ка не старая XP'шка. Система стабильна, у многих стоит на рабочих станциях, в школах, у бизнеса.
Но Microsoft решила что хватит. Кто не перешёл на Windows 11тот «выпал из эволюции».

Проблема в том, что половина мира просто не может перейти. У кого-то процессоры без TPM 2.0, у кого-то старое «железо»,
а у кого-то банально нет желания менять ноут который и так нормально работает.
И вот тут в игру входит Linux.

Linux всегда был где-то рядом с «теми, кто шарит».
А теперь к нему придут обычные пользователи и не потому что «open source»,
а потому что Windows их выкинула.

Microsoft сама создала рекламную кампанию конкурента:

– отказ от бесплатных обновлений безопасности;
– платные «Extended Security Updates» (ESU) для бизнеса;
– предложение купить новое железо ради Windows 11.

И люди пойдут по наименьшей силе сопротивления:
«как перейти на Linux»,
«какой дистрибутив проще»,
«что выбрать вместо Windows 10». Поисковики закипят.

Разработчики Linux-дистрибутивов даже сделали сайты вроде endof10.org, где показывают, как за 15 минут перейти на Linux Mint или Fedora.
Почти без боли и команд в консоли. С нормальным интерфейсом, без слежки и телеметрии.

Знаете, что самое ироничное?
Microsoft десять лет убеждала всех, что Windows 10 — «последняя версия». Теперь оказалось, что в смысле «последняя, которую вы получите бесплатно». Может это и есть настоящая точка невозврата.
Когда люди начали понимать: не нужно платить, чтобы иметь стабильную систему. Не нужно покупать новый ноут ради «обновлённого дизайна панели задач». Не нужно быть «айтишником», чтобы поставить Linux и забыть про постоянные обновления, перезагрузки и рекламу в меню «Пуск».

Microsoft сделала всё правильно с точки зрения бизнеса.
Но с точки зрения пользователя это просто идеальная реклама того, что у тебя есть выбор.

#Programming #ItSecurity

Кэширование

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

Но вот беда — всё, что хранится в нём может достаточно легко утечь.
Кэш часто содержит куски страниц, запросов и сессий, а если разработчик не подумал о настройках заголовков вроде Cache-Control, Pragma или no-store,
то приватные данные пользователя могут спокойно сохраниться прямо в трусах в сервера.

Бывает и хуже

Например, прокси-сервер или CDN (Cloudflare, Nginx, Varnish) кэшируют ответ,
а потом показывают его другому пользователю. И всё — чужой JSON с именем, адресом и токеном доступа уже в чьём-то браузере.

HTTPS тут не спасает, если внутри всё кэшируется без головы. Шифрование защищает транспорт, но не то что хранится после.
Кэш можно предоставить как сейф без замка: можно быстро достать, но и легко потерять.

А ещё есть браузерный кэш.
Ты заходишь в интернет-банк, выходишь, но если браузер не сбрасывает данные, то HTML и даже части запросов остаются в памяти устройства.
На чужом компе это уже не «ускорение загрузки», а риск утечки.

Кэширование похоже на нож.
Если пользоваться с умом, то ускорит и спасёт ресурсы.
Если нет, то начнет резать по живому. (Все вдоль а ты поперёк)
Особенно когда речь о данных, которые никому видеть не стоит.

#OpenSource

Новая лицензия ПЛМПНЗ.
Добиваемся ее использования во всех новых проектах!

Публичная лицензия, по которой можно пиздить, но нельзя закрывать (ПЛМПНЗ) версии первой

Для защиты открытого исходного кода программы, далее просто исходного текста, существует настоящая Публичная лицензия, по которой можно пиздить, но нельзя закрывать (а еще потому что GPL скучная хуйня)

Данный исходный код принадлежит этому человеку: дябло, а так же сообществу, вносящему свой вклад в это произведение искусства (да-да, программы, особенно попенсурс, тоже искусство)

Что есть что:
Бинарник - результат компиляции исходного текста в двоичный код или в другой текст (не обязательно состоящей из 0 или 1, это устоявшееся выражение, мне похуй, понимаете?), еще эту хуйню может запустить пользователь без дополнительной компиляции (интерпердаторы не в счет)
Исходный текст - текст, он же код, который написал настоящий разработчик настоящей программы, будучи в трезвом (исходный код читаем) или не в трезвом (исходный код нечитаем) состоянии, могут быть использованы средства вайбкодинга (то есть некоторые фрагменты написаны с помощью нейросетей, зачастую мало чем отличается от кода, написанного в нетрезвом состоянии)
Компиляция - процесс преобразования исходного текста в другой формат, например в другой текст, написанный на другом языке программирования, или вообще в циферки (которые только в бинарной система типа 1 или 0, поняли да?)
Форк, она же вилка, оно же ответвление (я буду называть вилкой, потому что смешно) - другой исходный текст, производный (то есть основан) от данного исходного текста программы.
Интерпретатор - программа, который выполняет код (в том числе и исходный текст), по сути любая программа исполняется внутри интерпретатора, который поставляется вместе с операционной системой или вы его скачивается (например питухон (он же Python))

САМА ЛИЦЕНЗИЯ:
1. Вместе с бинарником обязан поставляться исходный текст (либо отдельно, но исходный текст всегда должен быть доступен без ограничений)
2. Если исходный код автор захотел закрыть, то он становится петухом, ибо охуел, увы в суд его повести нельзя
3. Кстати форки нельзя закрывать, если они лицензируются под этой лицензией, но в этом случае автор может стать петухом не только в попенсурс камунити, но и на зоне
4. Нельзя запрещать пользоваться программой вне зависимости от целей пользователя (даже если пользователь экстр*мист (мы если что осуждаем), но автор за это не отвечает)
5. А, кстати, программа поставляется в таком виде в каком есть, но так как программа попенсурс, то вы вольны её улучшать
6. Ещё, если программа является цифровой платформой, то есть ей пользуются другие люди удалённо (она если, что находится не на их компе, а находится типа далеко-далеко на сервере, а не типа удаляют пользователя или программу), то эти пользователи тоже должны видеть это произведение чуда (то есть исходный код)
7. Если цифровая платформа хочет следовать законом (ну точнее обязана), то пользователи всегда могут сделать вилку от этого проекта со своими правилами и т.д.
8. Ну кстати исходя из всего этого крайне нежелательно использовать всякие системы защиты авторского права, ибо они нахуй не нужны

Ну это основные положения пока что, лицензия может улучшаться, она совместима с GPL кста, вроде как

(From DiabloSat_off)

#Education #Programming

Архитектура проекта

Знакомо чувство, когда смотришь на свой код трехмесячной давности и хочется выколоть себе глаза? Или когда простое изменение растягивается на неделю, потому что всё рассыпается,как карточный домик?

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

Архитектура это не про красивые диаграммы для начальства, а про то чтобы вам самим не было мучительно больно за свой код через месяц, полгода или год. Это стратегия «не обосраться», воплощенная в коде.

Почему все летит в помойку?

Хаотичное разрастание. «О, тут нужно добавить одну фичу...» — и вы лепите её прямо в ядро, создавая спагетти-зависимости. Через 10 таких фич ваш код превращается в болото, в котором тонет любая попытка что-то изменить.

Сломанная модульность. Модули знают друг о друге всё. Изменение кнопки на фронтенде ломает логику на бэкенде. Это как если бы двигатель вашей машины глох каждый раз, когда вы меняете цвет кузова.

Иллюзия «сначала сделаю, потом перепишу». Этого «потом» никогда не будет. Legacy-код работает как канализационная труба: чем дольше ждешь, тем страшнее в нее лезть.

Принципы, которые спасают репутацию

Здесь нет серебряной пули, но есть бронежилет от вашего же будущего «говнокода».

1. Принцип единственной ответственности (SRP)
Это святое. Один модуль = одна работа. Не «менеджер пользователей», который и в базе работает, и письма рассылает, и логи пишет. Это три разных модуля. Похерить этот принцип всё равно что гарантированно получить монстра, которого никто не посмеет тронуть.

2. Слои, как в торте
Четкое разделение на:

Слой представления (UI): только кнопки, формы и отображение. Никакой бизнес-логики!

Бизнес-логика (Ядро): самая важная часть: чистые правила, ради которых все затевалось. Она должна быть ИЗОЛИРОВАНА от всего внешнего.

Слой данных/Инфраструктура: работа с БД, внешними API, файловой системой.

Чем выше уровень, тем он важнее. Бизнес-логика не должна знать, какая у вас БД — PostgreSQL, MongoDB или текстовик на пергаменте.

3. Инверсия зависимостей
Ваше ядро не должно зависеть от базы данных, наоборот, БД должна «подключаться» к ядру через интерфейс (абстракцию). Хотите поменять базу? Просто реализуйте тот же интерфейс — ядро даже не узнает что что-то поменялось.

4. Доменно-ориентированное проектирование (DDD)
Это уже высший пилотаж. Вы сначала проектируете не таблицы в БД, а модель предметной области (домен) на языке бизнеса. «Заказ», «Пользователь», «Оплата» — это не просто классы, а объекты со своим поведением, инвариантами и правилами. Когда бизнес-логика выражена в коде так же четко, как в требованиях, то составить финальный продукт становится гораздо легче.

Так с чего начать?

Рисуйте. Прежде чем писать код, набросайте схему взаимодействия модулей на салфетке (можно даже в кофейне с маком за 10000к). Кто от кого зависит? Кто за что отвечает?

Задавайте вопрос «А что, если?..». «А что, если нам придется сменить провайдера платежей?», «А что, если нужно будет добавить кэширование?». Ответы на эти вопросы и рождают гибкую архитектуру.

Декомпозируйте. Любую большую задачу можно и нужно разбить на маленькие, независимые модули. Собирайте проект как LEGO, а не как скульптуру из глины.

Архитектура это не про то, чтобы сделать всё «идеально». Это про то, чтобы минимизировать стоимость изменений. Хорошая архитектура позволяет вам вносить правки быстро и без страха, плохая (или её отсутствие) — превращает каждое изменение в квест.

Стройте так, чтобы ваш код через полгода вызывал не желание переписать всё с нуля и откатиться из жизни, а тихую гордость: «А ведь я сделал это хорошо».

Не обмазывайтесь. Проектируйте.