>>182530
Компьютер UEFI-загрузку поддерживает?
А другой диск в системе есть?

Лично мне в таких случаях всегда GPT импонирует.

>>182532

>UEFI

Нет.

>другой диск

Нет.

Ну перетасуй как-нибудь данные между разделами и сами разделы (я имею ввиду изменение их размера), снеси какой-нибудь из них, предварительно скопировав данные.

>>182535
Есть некий виндовый "Зарезервированно системой", в каких случаях его можно снести?

>>182535
>>182536
И, да, пострадают ли файлы, если я сдвину левую границу раздела влево?

>>182537
Раз уж ты всё равно линуксы ставишь gparted умеет перемещать разделы корректно и не терять данные. Просто не делай заведомо бессмысленных действий, вроде уменьшения раздела меньше, чем размер его заполненности. Перемещение правой границы происходит обычно практически мгновенно, перемещение левой границы обычно влечет копирование чуть ли не всего раздела (данные теряться не должны, если дождешься окончания операции и у тебя за это время не вырубят свет).

>>182536
Гугл пишет, что это какой-то маленький раздел с загрузчиком, т.е. просто так сносить не стоит. Также гугл пишет, что как-то можно при желании перенести загрузчик с него на основной раздел и таки снести его.

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

>>182540
А ты уверен, что используемый тобою софт поддерживает перенос начала раздела?

>>182541
Пытался встроенной в винду утилитой и партед. Чем надо?

>>182542

>партед

Возможно должен уметь. GParted точно умеет, специально проверил - ntfs ресайзит тоже (через вызов сторонней утилиты ntfsresize). Если нужно под винду, то вроде были Partition Wizard, Аcronis.

>>182543

>GParted точно умеет

livecd peppermint не умел, видимо надо было

>(через вызов сторонней утилиты ntfsresize).

Ставлю Линукс, Федора предлагает такое деление разделов.
Так хорошо?
Или лучше выделить отдельное место для /home?
В спящий режим компьютер сможет уходить? На борту 8 гигабайт.
Как поменять на нормальные JEDEC-приставки?

>>182536
Это вендовый /boot

>>182550
Я наверно буду в меньшинстве но не считаю классическое деление на разделы актуальным если не нужна всякая экзотика в /boot
swap можно и в файл положить, разницы в скорости не заметно, особенно на ссд.
/home лучше использовать как AppData в винде, а свои документы-торренты держать на другом диске или разделе в /media/diskname

>>182550
Поставишь swap меньше чем памяти - не будет работать hibernate (suspend to disk), только обычный suspend (suspend to ram). Лично я считаю нужным выделять /boot только когда это оправдано схемами вроде использования шифрования. А вот раздел под /home считаю удобным.

>>182553

>Поставишь swap меньше чем памяти + swap занято в данный момент * эффективность сжатия - не будет работать hibernate

Починил

Линус-тред, а без swap'а же можно легально работать? ОЗУ 16 ГБ и столько места на ssd просто жалко.

>>182562
Кончено можно, если ram хватит. Но hibernate работать не будет. Разница в том, что со свапом когда ram кончается оно торомозить начинает, если памяти не хватает, а без будет сразу падать. Возможно небольшой свап лучше всё же поставить для уменьшения фрагментации памяти и более эффективного её переиспользования. Хотя у меня самого тоже 16gb и сижу без свапа, вроде не умер.

>>182563
Падать ничего не будет. Сейчас на дефолтных настройках, если мне не изменяет память, OOM Killer на самую жрущую вещь срабатывает намного раньше чем доходит до полного заполнения памяти и начала активного свапа.

>>182564
Ну не падать, так убиваться. Будто бы для юзера какая-то разница есть.

>>182565
Есть, конечно. Существуют ситуации, когда в случае oom вместо убивания процессов следует крашить всю машину. Поэтому, например, существует такой параметр как vm.panic_on_oom.

>>182550
Нет. Лучше сделать отдельные разделы под /tmp, /var, /usr и /home.

>>182574
Зачем?

>>182574
Под /usr отдельный раздел сейчас ни в коем случае не рекомендуется делать: https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/.

>>182574
/tmp сейчас на большинстве машин и дистрибутивов монтируется как tmpfs в памяти.

>>182576

>systemd

Хотел было начать "а раньше когда не было этой хрени всё было хорошо", а потом оказалось, что оно здесь не при чём.

>>182578
Оно всегда так было. Уж больно ведь упорото раньше шло разделение на то, что из бинарников идет в /{bin,sbin,lib}, а что в /usr/{bin,sbin,lib}. А эти ведь бинарники часто хотят свои данные подтянуть, которые в /usr/share.
Вот и получилось, что без /usr все равно ничего не работает, так что он нужен как можно раньше.

>>182579
Да оно и сейчас есть. Что там в /bin и /sbin (системное), что в /usr/bin, а что в /usr/local/bin. А что вообще в своих папках в /opt (там уже ШИNDOШS-стайл - для каждого приложения своя папка, но там обычно всякое ПО, которое нужно для конкретных целей, дающих конечный результат работы сервера, а не для облегчения жизни админа - там Java JDK, Oracle Database, Apache, интерпретатор Perl и прочие радости, хотя и системные утилиты, а также "тяжёлое" системное ПО).

>>182580

> perl в /opt

WAT?

>>182582
А апач в /opt тебе не показался странным?

>>182580
Сейчас уже почти нет. На многих дистрибутивах /bin, /sbin и /usr/sbin являются симлинками на /usr/bin. Аналогично с /lib и /lib64, которые симлинки на /usr/lib. Другие дистрибутивы медленно, но подбираются к такой схеме.

В /opt, насколько я помню обычно ставится всякое бинарное, распространяемое не через пакетный менеджер. А в /usr/local — собственноручно собранное.

Apache и Perl в /opt — это, конечно, нечто очень странное. Разве что это конфигурация в которой они собраны админом с какими-нибудь патчами и для облегчения контроля за их деплойментом, обновлением и удалением установлены в обход пакетов в /opt.

>>182584
Тащемта, например, Джава ставится в /opt из пакетов, например. Апач (который из официального репозитория, а не из пользовательских, где он, например, даже уже GCC собран) тоже ставится туда же. И пых. Постгрес (который обеспечивает нужды системы) тоже там (но он уже установлен туда не через пакетник, а находится там по дефолту).

>>182596
По поводу этих директорий — все равно сейчас разворачивать что-то без использования контейнеров - это бред, поэтому какая разница где что лежит? Чем проще, тем лучше.

>>182596
Это в каком это дистрибутиве? В моём дебиане там точно нет ни апача, ни пиэйчпи, ни OpenJDK. Всё установлено из официального репозитория дистрибутива.

>>182597
Можно какой-нибудь хендбук для начинающих по LAMP в контейнерах?

>>182582>>182583>>182584>>182596

>>183168
HP — это особое ынтерпрайзное извращенство.
Они, наверное, в /opt положили все то, что не написали сами, не так ли?

>>183169
Наоборот. Всё своё любимое у них в /opt (немного ещё в /usr, ну и, понятное дело, всякие вещи от самой ОС лежат в /bin, /lib, /etc), а всё совсем стороннее, что скомпилировано вне стен HP (или собирается пользователем), кладётся в традиционные /usr/local.
Алсо, официальные инструкции строго запрещают добавлять в PATH путь /usr/local/bin.

>>183211
Так по перлу и апачу в /opt я лично подумал, что они все то, что скомпилированно ими, а написано кем-то другим, ложат в /opt, а системное и написанное внутри HP ложат в /usr. Не так ли?
Или все-таки в /opt есть что-то из того, что написано для этой системы в HP?

>>183212
Собственное у них тоже в /opt - как видишь, там дислоцируется компилятор (aCC), IntegrityVM (hpvm), веб-морда операционки (hpwebadmin - да, там есть такая наркомания - более того, через веб-интерфейс можно конфигурировать ядро) и прочие вещи.
То есть, проще говоря, в /opt лежит всё, что поставляется из коробки, либо что можно скачать с официального репозитория HP.
В /usr тоже лежит что-то искоробочное (например, CDE). Что ещё там - не помню.
Честно говоря, не особо понимаю, почему они пихнули это в /opt, а не в /usr.