The9S

Тут вопрос в том, насколько нормальное питание в розетке. Если часто отключают, и нестабильное (может быть и более 250 и менее 180) - то стоит выключать. Если не скачет, и аварий нет - то пусть включен.
В дежурке комп потребляет немного, и кроме того, не расходуется батарейка часов (CMOS), на материнке которая. Если комп не выключать, она лет 10 может прослужить. Выключать на ночь - через пару лет нужно будет новую купить. Мелочь, а когда невовремя сдохнет, неприятно. Некоторые компы глючат когда её напряжение снижается до 2,7...2,5В, или вовсе не запускаются.
При вероятности грозы нужно выключать, но не тумблером, а вытаскивать вилку из розетки. При этом монитор с компом должны остаться включены по питанию в один удлиннитель, с общим третьим проводом, а удлиннитель уже вытащить из розетки. Отключить также локалку и всё что в звуковушку идёт. Иногда может прилететь по проводу клавы или мышки, или ещё чего по USB, но это параноиком надо быть, чтобы всё это отцеплять.

По поводу монитора - они в большинстве своём потребляют мало, когда в дежурке, НО конденсаторы на плате питания всё равно под напряжением, и они быстрее выйдут из строя, если всегда включены. В БП компа аналогично. Правда, большой разницы нет, они и без напряжения всё равно испортятся, какие-то раньше, какие-то позже. Просто это будет или 2 года, или 5, или у качественных 8-10лет.

В итоге каждый решает сам. Есть ещё вопрос пожарной безопасности - если техника не используется, она должна быть обесточена. А дома, кроме того, у кого-то есть кошки, которые по ночам любят проводами поиграть и погрызть... И ещё куча факторов. Да даже если розетку дёргать туда-сюда ежедневно, через полгода уже разболтается, и это грозит серьёзными проблемами, вплоть до пожара. Что по вопросу экономии электроэнергии - так намного большей экономии можно добиться банальной настройкой яркости монитора. Исходно стандартно стоит 50%, а это очень ярко, особенно на новых мониторах (если он не 7-8 лет отработал), стоит снизить до 30 и глазам будет комфортнее, и расход меньше. А если ОС поставить не винду, которая то обновы в фоне качает, то антивирус что-то постоянно делает, то ещё что-то грузит проц; а Linux/FreeBSD - то и ещё можно на электричестве сэкономить. Особенно, если энергосбережение настроить.

Про "отдых" компу уже сказали - ему можно и круглы сутки пахать, они на это рассчитаны. Я на обычном домашнем компе лет 7 держал игровой сервер дома. Круглые сутки. И не особо-то много за свет платил. Один кондиционер летом съедает за неделю больше чем комп за год.

Практически такая же как с Windows она есть но очень малеленькая.
Гораздо больше вероятность по ошиьбке лично поудалять случайно файлы.
---
И во первых - если ОС не грузится, ваши файлы то никуда не денутся, их можно будет скопировать.
Во вторых на любой системе желательно иметь резервные копии, так как любой диск может сдохнуть с гораздо большей вероятностью чем потеря файлов из-за обновления .

Если переживаете за сохранность каких-то важных файлов, то рекомендую хранить их на отдельном от Linux разделе, или вообще на отдельном жёстком диске, возможно даже форматированном в NTFS, чтобы можно было легко получить к ним доступ на другом компьютере в случае необходимости.

Это немного снизит риск потери файлов при переустановке системы, если, допустим, вы по ошибке форматируете весь диск вместо системного раздела. Из минусов - NTFS под LInux работает немного тормознее, чем родные файловые системы Linux (ext4, btrfs) - для обычного хранения документов и видео/музыки это не критично.

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

Интересно, всю жизнь использовал win7 и не боялся за файлы :) А теперь собирается использовать намного более надежную систему - и боится :)

Разумеется не нужно тащить туда виндовые привычки :) и все будет хорошо.

Вашим файлам в первую очередь угрожает не то, что вы

хочу переехать на manjaro

, а то, что вы

всю жизнь использовал windows 7

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

Посмотреть модели с предустановленным Линуксом. На них он будет работать точно.
Навскидку: Dell.

В свое время тоже вставал перед выбором deb или snap. Изучил этот вопрос максимально, на сколько это было возможным. Чтобы сделать правильный выбор, нужно понимать, как это работает.

Начну по старшенству - с deb. В традиционном мире deb наша операционная система Linux обладает списком источников софта, которые называются репозиториями. Есть официальные, которые хранятся тут: /etc/apt/sources.list и не официальные, которые хранятся тут: /etc/apt/sources.list.d/.
Устанавливая софт через GUI или CLI, установщик вначале скачивает с репозиториев списки доступного в нём софта. Софт, как сложный программный продукт, традиционно разбивается на логические части, идущие в различных пакетах, для этого требуется обработать зависимости с помощью ресурсов вашего ПК, этот процесс называется full dependency resolution. Установщик deb пакетов скачивает их с репозитория в каталог типа /var/cache/apt/archives/, распаковывает их содержимое по тем абсолютным путям, что идут в пакете deb. После команд типа apt clean пакеты в /var/cache/apt/archives/ будут удалены, так как они выполнили свою задачу и больше не нужны.
В deb программу дробят на различные пакеты, выделяя библиотеки/плагины/фреймворки в отдельные пакеты, чтобы делить их с другими программами. Классический пример, программа А идёт в пакете a.deb и зависит от пакета openssl.deb и программа B из пакета b.deb, зависит так же от openssl.deb. Получается, что программа А и В делят между собой (share) общую библиотеку из openssl.deb, т.е. зависят от одного и того же пакета openssl.deb.

В мире snap понятия зависимости не существует. И один snap пакет с программой не зависит от другого snap пакета. Программа внутри snap сжата со всем необходимым ей с помощью squashfs. Пакет скачивается с хранилища в виде snap package в каталог /var/lib/snapd/snaps/ и никуда и никогда не распаковывается. Пакет с программой монтируется в каталог /snap/[name]/[version]/. Snap программу упаковывают вместе с тем, что ей необходимо для работы. Например, внутри пакета a.snap есть файлы программы А и openssl и внутри пакета В есть файлы программы В и openssl.

Когда придумывали формат snap, хотели прежде всего отказаться от full dependency resolution. Скорее всего каждый встречал ситуацию, когда разрешение зависимостей заканчивалось ошибкой. Нужно было пробовать решить ситуацию командами типа sudo apt-get install -f. Можно было попробовать переустановить пакет с установкой дефолтных настроек. Это всё является не надёжностью в мире серверов и десктопа, а в мире мобильных устройств, для которых готовили формат snap - смертельно. Например, как на маломощном устройстве решить ситуацию при вероятной проблеме? Тем более full dependency resolution довольно таки затратная операция для CPU. Нужна была надёжность в лице атомарности:
1. Скачал snap пакет.
2. Не затратно для CPU примонтировал пакет, без full dependency resolution, без распаковки.
3. Получил новую версию программы.
4. Если новая версия программа будет вызывать проблемы, то можно легко откатиться к старой версии, перемонтировав на старую версию пакета.

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

Все программы внутри snap пакета изолированы от операционной системы и друг от друга профилем мандатного доступа AppArmor. В терминах snap технологии - это интерфейсы (interface). Интерфейс - это когда plug соединён со slot. Хотите из программы звук? Просите при упаковке программы через snapcraft.yaml, чтобы plug pulseaudio соединили с одноимённым slot pulseaudio в системе (пакет ubuntu-core). До этого момента все slot предоставляла операционная система через snap пакет ubuntu-core. То есть все программы, стыковались (connect) только со слотами системы и получали требуемое. Разработчики реализовали интерфейс connect и стало возможно snap А соединить со snap Б. На примере фреймворка KDE можно увидеть, как разработчики использовали данное решение. Первые пробы упаковки KCalc выдавали snap пакеты по 70 мб из-за kde-frameworks-5 внутри, но стоило воспользоваться интерфейсом connect и вынести kde-frameworks-5 в отдельный snap пакет, то KCalc похудел до 300 кб. Связь между snap пакетами описывается в snapcraft.yaml, который добавляется в пакет при упаковке. Snap позволяет в операционной системе обладать несколькими версиями библиотек и просить коннект к нужной при необходимости.

Теперь рассмотрим различия в работе программ, установленных из deb и snap пакетов. Большинство Linux систем - это discretionary access control (DAC). Вы установили программу А и при запуске её бинарника, в памяти он становится понятием - процесс. При запуске программы от своего имени процесс будет обладать теми правами, которыми обладает наша учётная запись. Если мы можем зайти в папку /share/folder_x/ и прочесть файл secret.txt, то и программа А сможет это сделать. В традиционном мире Linux мы надеемся на порядочность программистов, пишущих софт, и на внимательность сопровождающих пакета, которые пытаются не допустить злоупотреблений, например, отправляя к себе наши файлы.
Мир snap - это mandatory access control (MAC). При упаковке программы в декларативном виде описывают многие вещи в файле snapcraft.yaml, в том числе к каким интерфейсам должна подключаться программа. Эти желания будут развёрнуты в правила системы мандатного доступа AppArmor и проанализировать их можно по адресу /var/lib/snapd/apparmor/profiles/.
MAC строже чем DAC. Программа находится в изоляции и может только то что ей разрешено профилем. Запущенная snap программа А не сможет зайти в /share/folder_x/ и прочесть файл secret.txt при всём её желании. После установки программы в виде snap пакета, любой её бинарник не сможет что-либо считать, кроме как из пути /snap/[name]/[version]/.
К плюсам snap можно отнести то, что при любых изменениях в операционной системе, можно быть уверенным, что программа "не поломается" из-за изменений в библиотеках/фреймворках. Установил раз - работает всегда. Нет проблем при установке и обновлении софта. Всегда свежий софт от разработчика, без промежуточных звеньев в лице сопровождающего. Нет никаких привязок версии софта к версии системы, библиотек, фреймворков и т.д.

DEB:
- Программу с её библиотеками представляют в виде множества пакетов, которые зависят друг от друга.
- Deb пакеты скачивают, распаковывают содержимое, выполняя рихтовочные control скрипты.
- Программа из пакета deb ничем не ограничена и получает доступ ко всему к чему у вас есть права.
- В мире deb сложнее осуществляется версионность. Откат к старой версии может быть технически невозможен, ибо в репозитории может отсутствовать старый пакет к этому времени. Процедура понижения версии (downgrade) непроста и редко используется в практике. Атомарность не гарантируется. Все стараются, чтобы при обновлении всё прошло гладко, но не всегда система может быть переведена из одного рабочего состояния в другое.

SNAP:
- В snap пакете обычно идёт программа со всем необходимым ей. Иногда тяжёлые фреймворки выносят в отдельный snap и делают к нему connect.
- Snap пакет скачивают и монтируют в каталог, ничего никуда не распаковывается. Внутри сжатого пакета snap нет каких-либо скриптов, которые вызываются кем бы то нибыло.
- Программа в snap пакете работает в изоляции. Получает нужное через интерфейсы и не получает какой-либо доступ, даже если у вас есть на это права.
- Snap пакеты поддерживают атомарность и версионность. Вы можете откатывать софт к версии ранее и пакет или ставится полностью или не ставится совсем, если есть какие-то технические проблемы.

Во-первых, они ведут себя именно как вирусы, модифицируя содержимое исполняемого файла.

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

В-третьих, многие из кряков (например, KMS-активаторы), создают на ПК резидентную службу, регулярные задания, занимают порт, то есть ведут себя, как типичный бэкдор.

Ну, и в-четвёртых, как утверждают люди с шапочками из фольги, "эта всё сговор транснациональных карпараций и праизвадиилей антивируснава ПэО штоби люди покупале праграмы". Рассматривать эту теорию мы, конечно, не будем.