nafanja |
|
![]()
Темы:
94
Сообщения:
9252
Участник с: 02 июня 2012
заблокирован
|
атрибут только чтение, и ничего затереться само не сможет. да и вообще бут отдельным разделом это классика, уже давно продуманно, зачем, почему и как лучше… и ни кто не запрещает делать как хочется…
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874 |
maxys146 |
|
![]()
Темы:
43
Сообщения:
754
Участник с: 08 апреля 2011
|
Ну да, а если основной системой стоит та у которой ядто это симлинк? Симлинки при обновлении менять придется ручками что-ли, еслитолько для чтенияони будут? А ядро арча как обновится если на его месте будет симлинк? Вообще без ядра система будет? Нет это все костыли, если много систем на винтак, то или у каждого свой /boon-раздел(штуки 3 на винте нормально? Нет)) ), либо бут у каждого в корне свой, а загрузчик один. Вообще по сути что такое загрузчик? это в первую очередь запись в MBR, а конфиги и прочая тряхомудина которая лежит в /boot это настройки программ которые переписывают mbr и по сути нужны-то только один раз(ну да, гроб наворотили, ему постоянно все надо, согласен, но у меня на одной машине еще lilo стоит, вот не нарадуюсь и сносить не хочется)) ), а в разделе /boot по идее только ядро и загрузочный образ должен лежать, так и было изначально задумано. Делался отдельный раздел для того чтобы загрузить ядро в родной ФС и корень можно было подключить уже находящийся на любой файловой системе. То что потом гробы стали хранить в /boot свои файлы это уже другой разговор, /boot каталог для ядер и загрузочных образов, загрузчик по сути это запись в mbr а не софт который ее редактирует. С неразберихой в дистрибутивах(я делаю как сам хочу) вы будете больше костылить если будете держать все ядра от разных дистров в одном разделе, стандартов-то нет. Вот если-бы ыбл единый стандарт как обзывать ядра и делать на них симлинки для ВСЕХ дистрибутивов, то я в первую очередь вынес-бы /boot в отдельный раздел и ядра всех дистров хранил там, это было-бы правильнее, но в настоящее время это только лишние геморои на свою голову… |
sleepycat |
|
![]()
Темы:
98
Сообщения:
3291
Участник с: 19 июля 2011
|
на старом винте 5 систмем, ну баловался я, (бут раздел, фат 32 общий для всех “юней”, овец водит grub4dos) xp,7,mandriva,debian,freeBSD. Слежу(ил) за обновлениями ядер, вносил правки в конфиг загрузчика соотвественно руками и до сих пор считаю такой метод тру вариантом, исклуючение раз уж что второй гроб. Я никак не пойму в чем сыр бор? пускай делают люди так как хотят. Даже “мне просто так нравиться” тоже повод сделать чтото так, а не иначе ;) PS: загрузчик можно поделить на несколько частей, для лучшей передачи смысла можно временно назвать их модулями, так вот те несколько строк помещеные в мбр, это только первый из модулей ;) PS2: Вы не поверите, но разные линуксы иногда нормально грузятся даже не со своих ядер, лиш бы версии были близкие, была даже идея обновлять только одно ядро для всех, но я
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
|
maxys146 |
|
![]()
Темы:
43
Сообщения:
754
Участник с: 08 апреля 2011
|
Хехех, тогда на любой вопрос типа “как лучше сделать, так или так?” надо отвечать “Делай как тебе нравится”?;))) Для того и развели тут холивар чтобы понять в каких ситуациях одно решение больше подходит, в каких другое) Я не ставил себе целью оскорбить кого-то или нагрубить, просто действительно интересно почему кто-то не разделяет мою точку зрения и если мне докажут что это правильно и лучше я спорить не буду))) P.S. …который по сути и делает всю работу, все остальное это его управлялки и конфигурялки P.S.2. Знаю, пробовал, вот только собраны они зачастую по разному, что-то может быть модулем, а у другой системы это включено в монолит, и в итоге окажется что ни в ядне ни в моделях не окажется нужного модуля, так что общее ядро это не вариант)) PlayStation3 собирать будем?;) |
sleepycat |
|
![]()
Темы:
98
Сообщения:
3291
Участник с: 19 июля 2011
|
maxys146классика инетного жанра. Cкладывается впечатление , что Вы оспариваете корректность вынесения бут каталога в отдельный раздел, особенно для одиночно (“стандалоне”) стоящей системы. А так стало сразу понятно. На Ваш корректный смысл, уточненный выше, можно сказать , что доказывать нечего, никто корректность расположения бут каталога в корневом разделе не оспаривает и не считает ересью, а весь текст явленный выше, как-либо комментирующий это, имхо, писался под неверно исталкованным смыслом , который как бы намекал о ненужности или не правильности расположения бут каталога отдельно и только косвенно относился к теме расположения бут каталога в корне…
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
|
sleepycat |
|
![]()
Темы:
98
Сообщения:
3291
Участник с: 19 июля 2011
|
P.S.2. Знаю, пробовал, вот только собраны они зачастую по разному, что-то может быть модулем, а у другой системы это включено в монолит, и в итоге окажется что ни в ядне ни в моделях не окажется нужного модуля, так что общее ядро это не вариант))а что , на пять-десять секунд оно будет дольше в память влезать, или займет на сотню другую метров больше на диске. Для современного железа это не проблема, и/а для человека, собравшего в ядро все что не лень , ради благой (нужной) цели, подождать даже двадцать секунд не зазорно ;) . Вот где лучше не спорить, тут холиваром пахнет и хорошо, что мы на форуме линукса, где сборка ядра ( ручная самовольная ) толи к беде толи к счастью редкость.
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
|
maxys146 |
|
![]()
Темы:
43
Сообщения:
754
Участник с: 08 апреля 2011
|
sleepycatЯ к тому если не пересобирать ядро а пользоваться тем что собирают разрабы дистра, у всех оно разное, тут даже можно не спорить))P.S.2. Знаю, пробовал, вот только собраны они зачастую по разному, что-то может быть модулем, а у другой системы это включено в монолит, и в итоге окажется что ни в ядне ни в моделях не окажется нужного модуля, так что общее ядро это не вариант))а что , на пять-десять секунд оно будет дольше в память влезать, или займет на сотню другую метров больше на диске. Для современного железа это не проблема, и/а для человека, собравшего в ядро все что не лень , ради благой (нужной) цели, подождать даже двадцать секунд не зазорно ;) . Вот где лучше не спорить, тут холиваром пахнет и хорошо, что мы на форуме линукса, где сборка ядра ( ручная самовольная ) толи к беде толи к счастью редкость. Конечно если самому собирать, то можно и /boot и /lib/modules делать отдельными разделами и не париться, будет одно ядро на все)) |
anode |
|
Темы:
7
Сообщения:
982
Участник с: 30 августа 2011
|
maxys146Один вопрос: как по вашему нафига в систему устанавливаются заголовочные файлы ядра? |
maxys146 |
|
![]()
Темы:
43
Сообщения:
754
Участник с: 08 апреля 2011
|
Хм, а они не только при сборке модулей нужны разве? Для работы системы достаточно самого ядра и его модулей насколько я знаю. |
anode |
|
Темы:
7
Сообщения:
982
Участник с: 30 августа 2011
|
maxys146Я имею в виду пакет linux-api-headers, то есть то, что находится в /usr/include/{asm,linux,sound,video…}, а от него зависит glibc, а значит все пакеты скомпилированные с динамическими библиотеками, то есть вся система. В принципе есть два подхода арчевский, он же слакваровский, когда устанавливается весь пакет вместе с заголовочными файлами и библиотеками для компиляции и дебиановский, он же рэдхатовский, когда библиотеки и *.h файлы устанавливаются отдельно пакетами с суфиксами -devel. В первом теряем место, если не собираемся заниматься сборкой пакетов, во втором получаем дополнительный гемор при необходимости что-то скомпилировать. |