mayton2019

Чтение книг тут вобщем-то не очень полезно потому что каждый автор описывает линукс применительно к каким-то промышленным решениям где сразу "всего много". Много хостов в сети. Много серверов приложений и хранилищ и много задач.

Изучать будет трудно. Линукс не прощает грубых ошибок. Если проводить аналогии то Windows - это электродрель где всё в резиновых ручках безопасно и красиво и удобно лежит в руке. С такой дрелью вам ничего не грозит. И можно сделать дырочки в стенах безопасно. А Линукс в этом сравнении - это строительный бур, которым вы можете снести стену, но и легко пробурить себе ногу. Тоесть когда вы начнёте эксперименты (особенно на привилегиях root) то думайте что по ту сторону нет вообще никаких защит. Удалить корень файловой системы одним жестом очень просто, как уже отметили выше.

Но для домашнего варианта можно придумать нечто вроде : создать свою мини-сеть с DNS, файрволом, прокси, и медиасервером для фильмов. Вот с этого можно начинать. Можно поднять игровые серверы Майнкрафта, фермы майнинга или генерации радужных таблиц. По поводу Mint - всё в принципе хорошо. Вообще важен не дистрибутив а скорость трабл-шутинга. И надо не боятся работать с консолью. Не надейтесь что если вы подняли Smb через UI - то это достижение. Нужно поймать траблу. Зайти в консоль и ее пофиксить. Я гарантирую что через UI большинство траблов не фиксятся. В этом есть особая философия. Поэтому и устанавливайте и конфигурите софт через консоль.

Дело в том что курсор может потреблять ресурсы. Например вы захотели взять первые 10 строк из 10000000 выборки но предварительно отсортировали. Выбрали 10 строк и не сделали финализирующие протокольные действия в Python. База данных будет удерживать в памяти алгоритмы и структуры данных для снапшота результата этого запроса до тех пор пока не придет явный CLOSE с вашей стороны либо интеллекуальный драйвер который еще и обладает логикой уборки мусора сам не догадается что Statement уже вышел из scope вашего использования и может быть удалён GC.

Я был свидетелем ситуации когда крупное ent-приложение Java/Oracle переполняло память из-за неверной обработки Exception и плодила много незакрытых курсоров в БД. Java от этого не сильно страдала (GC всё убирал) но страдал Oracle. Потому что уборка происходила слишком поздно. Пофиксилось тогда переписыванием с try на try-with-resources.

Поэтому если вы неряшливо обращаетесь с курсорами (явными и неявными (обычный select к примеру может прождать неявный курсор)) то не ваше приложение а база данных почувствует себя плохо. Как быстро и какие ошибки вы будете получать - зависит от настроек вашей БД.

Тут нечего думать. Смотрите что показывает explain plan и меряйте время отклика.

SQL как язык - это чистая теория. То есть известен результат но неизвестно каким способом конкретная dbms его достигает. Операция explain будет зависеть от выбора dbms (Oracle, Postgres e.t.c) и будет по разному показывать реализацию алгоритма выборки для каждого select.

Спрогнозировать как будет выглядеть план сложно. Даже разные версии Oracle к примеру могут показать разный план на одном тексте запроса.

Текстуры линейно накладываются только на плоскости. Всякие сферы и кривые поверхности требуют специального подхода.

Есть такое старое правило что сначала нужно писать тесты. Без тестов ты конечно можешь начать рефакторинг но если что-то сломалось то сложно будет детектировать поломку именно в тот момент. Это всплывёт позднее.

Далее без исходников сложно что-либо советовать. Тут - сколько людей столько и мнений.