Доступен (https://lists.debian.org/debian-devel-announce/2016/11/msg00...) для тестирования восьмой альфа-выпуск инсталлятора следующего значительного релиза Debian - "Stretch". В настоящее время дистрибутив находится на первой стадии заморозки пакетной базы (прекращено обновление пакетов, требующее корректировки зависимостей у других пакетов). 5 января 2017 года состоится мягкая заморозка пакетной базы, при которой будет прекращён приём новых исходных пакетов и закрыта возможность повторного включения ранее удалённых пакетов. 5 февраля будет применена полная заморозка перед релизом, при которой процесс переноса пакетов из unstable в testing будет полностью остановлен.
Основные изменения в Debian Installer Stretch Alpha 8:
- В debootstrap по умолчанию задействован перенос (https://lists.debian.org/debian-devel/2016/09/msg00269.html) всех исполняемых файлов и библиотек из корневых директорий в /usr. Каталоги /bin, /sbin и /lib* теперь унифицированы с соответствующими каталоги внутри /usr и оформлены через символические ссылки на них. Подобная реструктуризация позволит (https://www.opennet.ru/opennews/art.shtml?num=32914) избавиться от путаницы с размещением файлов и упростит (https://www.opennet.ru/opennews/art.shtml?num=32194) поддержание пакетов.
- Добавлена возможность использования утилиты GNU/screen для формирования многооконного консольного интерфейса;- Ядро Linux обновлено до версии 4.7 (в прошлой сборки использовалось ядро 4.6);
- Возможность использования сжатия xz для индексов Packages;- Поддержка загрузки и проверки файлов InRelease;
- В качестве зеркала по умолчанию теперь указывается deb.debian.org;
- В руководство по установке добавлен раздел для mips64el и удалены разделы для kfreebsd-* и powerpc;
- Состав пакета core-modules перемещён в kernel-image;
- В загрузчик добавлена поддержка EFI-систем на базе архитектуры armhf;
- Добавлена поддержка платы Orange Pi Plus;- В БД поддерживаемого оборудования добавлены устройства
Xunlong Orange Pi One, Xunlong
Orange Pi PC, Xunlong Orange Pi 2, DragonBoard 410c, Colorfly E708 Q1, Difrnce DIT4350, Dserve DSRV9703C,
Polaroid MID2809PXE04, HumanWare USB, NVIDIA Jetson TX1 Developer Kit.URL: https://lists.debian.org/debian-devel-announce/2016/11/msg00...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45488
>перенос всех исполняемых файлов и библиотек из корневых директорий в /usr. Каталоги /bin, /sbin и /lib* теперь унифицированы с соответствующими каталоги внутри /usr и оформлены через символические ссылки на нихvoid-linux way
>Добавлена возможность использования утилиты GNU/screen
Стоп. Вот не поверю, что раньше в debian не было screen. Может конкретно в инсталляторе такая возможность появилась? Уточняйте в новости подробные моменты.
> Может конкретно в инсталляторе такая возможность появилась?^ this
В Дебьяне был Screen.
>Уточняйте в новости подробные моменты.
>Основные изменения в Debian Installer Stretch Alpha 8:Что тебе еще уточнить? Пойди кофе выпей.
>не поверю, что раньше в debian не было screen
Всегда было.
>>Уточняйте в новости подробные моменты.
>>Основные изменения в Debian Installer Stretch Alpha 8:
> Что тебе еще уточнить? Пойди кофе выпей.Вот это, например:
""Any arch that can install with a console that supports switching between screens with “<alt>-Fn” does not benefit from having screen be default. It’s only when one is installing from a serial console (i.e. non-video) that it would be useful to have screen be the default."" --https://lists.debian.org/debian-boot/2016/08/msg00082.html
Расскажи ему ещй вот про это https://lists.debian.org/debian-boot/2016/02/msg00547.html и обозри все последовавшие 9 месяцев постройки и починки сей убер-фичи.
Тут всем будет интересно! Начинай.
Сказать-то че хотел? Он спросил, screen в инсталлере или в Дебе. Я и ответил. Нафиг мне твое инфо?
Возможно дело в том, что в последних выпусках systemd сломали screen? Суть в том, что как только пользователь закрывает свою последнюю сессию, тут же идет очистка от любых процессов запущенных от этой сессии. В то числе и от screen. Обойти этом можно, написав специальный юнит для screen. Наверное это и было сделано.
*тут должна быть шутка про костыли в SysVInit*
>void-linux wayКакой войд? Это идея, которую Поттеринг протащил. Гугли UsrMove
>> void-linux way
> Какой войд? Это идея, которую Поттеринг протащил. Гугли UsrMovevoid-poettering way
> void-poettering wayНа всякий случай напомню, что void linux основан идейным поттерофобом. И вместо инита там runit.
> поттерофобомВы так говорите, как будто это что-то плохое.
>> поттерофобом
> Вы так говорите, как будто это что-то плохое.Это замечательно! Особенно когда он продвигает ленькины идеи и поделки.
>>> поттерофобом
>> Вы так говорите, как будто это что-то плохое.
> Это замечательно! Особенно когда он продвигает ленькины идеи и поделки.Воу-воу. У Лёни не всё плохо. Обвиняют его в комбайне под названием "systemd" и агрессивном продвижение оного. Ни больше ни меньше.
А шо, пш-пш аудио уже простили?
Тут так часто и со вкусом говорят про "пш-пш", что, видимо, у меня одного оно ни разу за многие годы не пш-пш. Не повезло.
> видимо, у меня одного оно ни разу за многие годы не пш-пш.Это про тебя статья в районной газете была "100000 километров не пердел"?
> На всякий случай напомню, что void linux основан идейным поттерофобом. И вместо
> инита там runit.Может ему сразу форком openbsd стать заодно? Иначе недостаточно ретроградно :)
Гарри что ли? Или который Слаку сделал?
>>перенос всех исполняемых файлов и библиотек из корневых директорий в /usr. Каталоги /bin, /sbin и /lib* теперь унифицированы с соответствующими каталоги внутри /usr и оформлены через символические ссылки на них
>void-linux waysystemd-Potteringd во все поля
>>>перенос всех исполняемых файлов и библиотек из корневых директорий в /usr. Каталоги /bin, /sbin и /lib* теперь унифицированы с соответствующими каталоги внутри /usr и оформлены через символические ссылки на них
>>void-linux way
> systemd-Potteringd во все поляВот так, тихо и незаметно, борцы с Поттерингом продвигают его идеи.
Ждем в Devuan.
>Подобная реструктуризация позволит избавиться от путаницы с размещением файлов и упростит поддержание пакетов.И обеспечит дополнительную мороку при повреждении фс корневого раздела.
Зачем вы до сих пор живёте в 1995м и делаете /usr отдельным разделом?
>Зачем вы до сих пор живёте в 1995м и делаете /usr отдельным разделом?Мой комментарий как раз про то обстоятельство, что нынче делать /usr отдельным разделом смысла ровно 0.
И если, пусть не в 95-м (тогда я про никсы и не слышал), а в 2005, система могла выявить проблему в фс, автоматически запустить fsck, проверить непримонтированный (!) раздел и перезагрузиться, то нынче она в такой же ситуации вывалится в emergency mode: грузитесь с внешнего носителя, граждане.
так нонче есть initrd с fsck.
ведь не то что давеча.
> так нонче есть initrd с fsck.А как обрадуются разработчики embedded-устройств, которые до сих пор собирают ядро монолитно и без initrd.
>> так нонче есть initrd с fsck.
> А как обрадуются разработчики embedded-устройств, которые до сих пор собирают ядро монолитно
> и без initrd.systemd в embedded? Серьёзно?
Очень, при твоей жизни и ядро туда же вдолбят.
В смысле в systemd, а не в embedded.
> В смысле в systemd, а не в embedded.Примерно такие же шансы, как падение Земли на Луну.
systemd по сравнению с ядром Linux - мелкая, простая, узкоспециализированная утилитка.
> простаяСпасибо, ты сделал мой день.
А без него (без дней), как же ты живёшь?!
Веду ночную жизнь.
> Примерно такие же шансы, как падение Земли на Луну.Чуваки с хабры прочитав про успехи с EmDrive уже придумали - прикрутить движок помощнее, построить электростанцию и снять к чертям Луну с земной орбиты. Комический корабль king size готов.
>> В смысле в systemd, а не в embedded.
> Примерно такие же шансы, как падение Земли на Луну.
> systemd по сравнению с ядром Linux - мелкая, простая, узкоспециализированная бажная и слепленная на коленке утилитка.пофиксил, не благодари
> systemd в embedded? Серьёзно?systemd вообще никда не стоит. Серьёзно. :)
А речь вообще говоря про /usr merge, а не про systemd.
> systemd в embedded? Серьёзно?Абсолютно. Он не только работает, но
1) Система с ним грузится в разы быстрее и в эмбедовке это нужно.
2) С ним сложнее забить на ошибки и схалтурить, он позволяет отлавливать хитрозадые взбрыки систем.
3) В нем еще и обработать можно отвал критичных сервисов.
4) И мониторить живость критичных процессов он может, у него апи есть.
5) Он решает множество проблем, будь то установка релтаймного шедулера и прочих приоритетов или нормальная дележка ресурсов. Фанаты ulimit и nice дружно курят бамбук.Кста поцтера попинали совместными усилиями с подачи фирмочки pengutronix - системд теперь вполне себе живет и на readonly rootfs и всем таком прочем.
> он позволяет отлавливать хитрозадые взбрыки систем.А потом сам валится, но что там произошло не знает даже Поццеринг.
> А потом сам валится, но что там произошло не знает даже Поццеринг.Поцтеринг как раз такие вещи чинит очень оперативно, в отличие от всяких бракоделов. И вот что-что а я совершенно не заинтересован чтобы у меня эмбедовка валилась.
А вот шеллскрипты забивающие на ошибки, ждущие повисший сервис до бесконечности и не способные даже перезапустить сервис если он почему-то все-таки упал - это визитная карточка "ветеран юникс админов".
fsck в эмбеддедед? Это тот самый эмбеддед, который по характеристикам обходит сервера в 95ом?
> fsck в эмбеддедед?А что Вас так удивляет?
>> fsck в эмбеддедед?
> А что Вас так удивляет?Просто это уже не эмбеддед, а просто "девайс с маленьким кол-вом рамы / диска". А потому использование initrd там вполне уместно
> А что Вас так удивляет?То что в общем случае:
1) Никому не в кассу ждать его завешения работы. Могут быть требования к времени выхода на режим. И если fack будет вкалыать хзсколько - это фигово.
2) Внезапно в эмбедовке обычно нет пользователя для интерактивного взаимодействия с системой, а далеко не любой дестрой ФС однозначно чинится.
3) Если файлуха рассыпется или fsck починит что-то не то - система превратится в тыкву. И вы получите злого клиента и возврат/починку девайса. За свой счет.
4) Поэтому зачастую файлуху предпочитают держать по возможности RO, если это не факапит всю задачу. А если это не катит - берут файлуху которой fsck не требуется и которая разваливаться не склонна. Или городят варианты восстановления при сбое.
> А как обрадуются разработчики embedded-устройств, которые до сих пор собирают ядро монолитно и без initrd.Ну уж в embedded-то точно дофига носителей, и без usr на отдельном разделе никуда)
> Ну уж в embedded-то точно дофига носителей, и без usr на отдельном разделе никуда)Дофига - это сомнительный аргумент. На embedded дофига чего и вовсе на винде вертится. Что же теперь, gnu/linux закапывать, что ли?
> Дофига - это сомнительный аргумент. На embedded дофига чего и вовсе на
> винде вертится.Это делали такие же как вы, только еще и винд00зоиды к тому же. А зак@пывать никого не надо. Надо просто отправить дедушек на пенсию, вместе с sysv init. Они хорошо поработали, но мир теперь другой.
> нынче делать /usr отдельным разделом смысла ровно 0Так какие тогда возражения к изменению описанному в новости?
> И обеспечит дополнительную мороку при повреждении фс корневого раздела.
Если / и /usr это один и тот же раздел, какая морока и кому будет обеспечена в зависимости от того где бинарники, а где симлинки на них?
Я знаю в каких случаях нужен отльный var, tmp, home. Могу придумать зачем отдельный boot, но вот зачем отдельный usr я придумать не могу. Так что все нормально
> Я знаю в каких случаях нужен отльный var, tmp, home. Могу придумать
> зачем отдельный boot, но вот зачем отдельный usr я придумать не
> могу. Так что все нормальноА я вот даже зачем отдельный /var придумать не могу. Зачем выносить /var/lib(раз уж до сих пор, насрав на FHS, туда суют базы мускуля, постгри и ко) я понимаю, зачем отдельный /var/log или /var/spool понимаю, а зачем весь /var нет. А /tmp давно все нормальные люди суют в tmpfs, нечего ему вообще на харде делать.
> А /tmp давно все нормальные люди суют в tmpfsЭто потому что "нормальные люди" на своём локалхосте не сталкивались, скажем, с массовой обработкой картинок или звука. В /tmp в этом случае может тусоваться пара тысяч файлов по гигу каждый.
>> А /tmp давно все нормальные люди суют в tmpfs
> Это потому что "нормальные люди" на своём локалхосте не сталкивались, скажем, с
> массовой обработкой картинок или звука. В /tmp в этом случае может
> тусоваться пара тысяч файлов по гигу каждый.Малыш, ты прячешься за пакетом и размышляешь о реальных серверах, которых не видел в жизни. Я пишу под своим реальным именем и под ним же работаю админом с 1997 года. Что там про локалхост-то?
Ты не сри на сервере в /tmp, работай в директории пользователя и там обрабатывай, когда мамка разрешит сесть за комп.
Cрач в /tmp может вообще не зависеть от админа. Странно не знать этого работая с 1997 года.
> Cрач в /tmp может вообще не зависеть от админа. Странно не знать
> этого работая с 1997 года.Только от админа и зависит. Есть pam-tmpdir и юзеры в системный /tmp не лезут, а системный таки в tmpfs живет. А в свой домашний пусть срут, на это есть квоты.
Теперь осталось рассказать об этом разработчикам ПО. И да, тоже видел пайплайны в /tmp правда при обработке pdf-документов.
> пайплайны
> в /tmpЧто, простите?
Может, сокеты или FIFO? Но даже в этом случае у меня для вас неприятный сюрприз, связанный с тем, где хранятся их данные...
У разработчиков никогда не было модно делать свои дела в одном каталоге. У них модно цеплять левые репы, собирать и распихивать софт по всем уголкам системы. По этому контейнеры стали такие популярные, можно засрать всю систему и админ не заругает и сервак от этого не рухнет.
> Я пишу под своим реальным именемТы кто вообще?
>Малыш
>работаю админом с 1997 года
>когда мамка разрешитМда.
> Зачем выносить /var/lib(раз уж до сих пор, насрав на FHS, туда суют базы мускуля, постгри и ко)...Мне вот самому стало интересно и я решил ознакомиться с этим документом.
http://www.pathname.com/fhs/pub/fhs-2.3.pdf
33-34 страницы:
5.8. /var/lib : Variable state information
5.8.1. Purpose
This hierarchy holds state information pertaining to an application or the system. State information is data that
programs modify while they run, and that pertains to one specific host. Users must never need to modify files in
/var/lib to configure a package’s operation.
State information is generally used to preserve the condition of an application (or a group of inter-related
applications) between invocations and between different instances of the same application. State information
should generally remain valid after a reboot, should not be logging output, and should not be spooled data.
An application (or a group of inter-related applications) must use a subdirectory of /var/lib for its data. There
is one required subdirectory, /var/lib/misc, which is intended for state files that don’t need a subdirectory;
the other subdirectories should only be present if the application in question is included in the distribution. 3
/var/lib/<name> is the location that must be used for all distribution packaging support. Different
distributions may use different names, of course.Почему хранение БД в "/var/lib/mysql", по вашему, оскверняет FHS?
Я так понимаю, вы думаете, что БД должна хранится в "/srv/mysql"?3.16. /srv : Data for services provided by this system
3.16.1. Purpose
/srv contains site-specific data which is served by this system.
This main purpose of specifying this is so that users may find the location of the data files for particular
service, and so that services which require a single tree for readonly data, writable data and scripts (such as
cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users’
home directory.
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on
how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www,
and cvs. On large systems it can be useful to structure /srv by administrative context, such as
/srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program
should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.
However /srv should always exist on FHS compliant systems and should be used as the default location for
such data.
С английским у меня не очень, но в чём отличие переменных данных не редактируемых пользователем данных и site-specific данных обслуживающих эту систему?
Тут, как по мне, сам HFS вносит путаницу. Тогда уже и почту в /srv - это же тоже "site-specific данные обслуживающие эту систему", или нет?Но больше всего бросилось в глаза это.
14. This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but
require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and
/lib a symlink to one of them.
Вот это вот действительно пример массового забивания болта на FHS.
>> Зачем выносить /var/lib(раз уж до сих пор, насрав на FHS, туда суют базы мускуля, постгри и ко)...
> Мне вот самому стало интересно и я решил ознакомиться с этим документом.Исходя из духа FHS базы должны быть в /srv, так же как содержимое сайтов и так далее. /var должен содержать файлы утеря которых не повлияет на работоспособность системы. Вообще вынос данных в /srv это очень удобно. Я знаю, что вот у меня в /srv/web/domaintld лежат сайты, вот в /srv/db/mysql, /srv/db/pg(и так далее) лежат бд. И бэкапить удобней :)
Мне в свое время концепция /srv очень понравилась.
Файлы любых фтп-webdav и ко храню в /srv/files или /srv/data, а там внутри уже разбиваю по сервисам
Тут всё зависит от дистрибутива, если, конечно, у вас не Gentoo, так как при первом же обновлении будет каша, или в /var/lib/mysql должен быть тупо симлинк на /srv/db/mysql.
При автоматизированном или полуавтоматизированном бекапировании абсолютно всё равно где находятся данные.
Когда всё что касается серверов лежит в /srv - это красиво. С этим я не спорю, но тут вопрос эстетики зависит от вашего дистрибутива, в CentOS и www лежит в /var/lib, и переть против специфики дистрибутива уже не красиво.
> Тут всё зависит от дистрибутива, если, конечно, у вас не Gentoo, так
> как при первом же обновлении будет каша, или в /var/lib/mysql должен
> быть тупо симлинк на /srv/db/mysql.
> При автоматизированном или полуавтоматизированном бекапировании абсолютно всё равно
> где находятся данные.
> Когда всё что касается серверов лежит в /srv - это красиво. С
> этим я не спорю, но тут вопрос эстетики зависит от вашего
> дистрибутива, в CentOS и www лежит в /var/lib, и переть против
> специфики дистрибутива уже не красиво.Вот уж то что по дефолту апач и nginx считают, что что-то лежит в /var/www это вообще не проблема, ибо всегда в конфигах указываешь свой документ-рут, это не против логики дистрибутива.
Про симлинк да, держу для обратной совместимости симлинк именно так, как ты написал, но, опять же, при обновлениях и без него ничего не будет, ибо конфиг при обновлениях без моей воли никто не затрет.
А вообще рекомендую подумать над использованием /srv, это действительно очень удобно, когда у тебя все серверные данные в одной директории, по логике FHS именно так и должно быть, грустно, что никто ей не следует.
Отдельный /var нужен тогда, когда все остальное read-only.
> Отдельный /var нужен тогда, когда все остальное read-only.Специфичный кейс, не подумал о нем.
> Я знаю в каких случаях нужен отльный var, tmp, home. Могу придумать
> зачем отдельный boot, но вот зачем отдельный usr я придумать не
> могу. Так что все нормальноА я могу придумать зачем отдельный boot.
Когда есть повреждения на ФС. Например в корне. А там у тебя ёпт, ядро!
Ну например /usr может монтироваться как squashfs для защиты от перезаписи и ускорения доступа к файлам на медленных носителях за счет сжатия.
Нынче она в такой ситуации загрузится из initramfs и даст спокойно проверить все разделы вообще без участия всей остальной системы.
Т — теоретики.
> Т — теоретики.Ага, только вчера у меня по питалу полетела машина, ФС обиделась и все загрузилось из initramfs, но я — теоретик, а ты не знающий реальности у нас практик.
> Ага, только вчера у меня по питалу полетела машина, ФС обиделась и
> все загрузилось из initramfs, но я — теоретикЕсли еще не - скоро таковым станете. Нафига б продакшнам администрирование где при малейшем факпе какой-то высокооплачиваемый динозавр тратит уйму времени на какие-то левые действия? По современным понятиям так только локалхосты админят, а подобных ископаеммых замещают всякими девопсами, понимающими что за такое админу бошку снимают.
> Т — теоретики.И это говорит человек, не знающий про initrd. По сравнению с вами, даже прочитавший "линукс для чайников" семиклассник Вася уже практически профессор линуксовых наук)
>И это говорит человек, не знающий про initrd.Вообще-то, обсуждаемая ситуация немного не про это.
> Мой комментарий как раз про то обстоятельство, что нынче делать /usr отдельным разделом смысла ровно 0А мой комментарий как раз про то обстоятельство, что нынче не делать /usr отдельным разделом смысла ровно 0.
А кому оно принципиально, нехрена ломать обратную совместимость, используя микроскоп и гвозди.
> А мой комментарий как раз про то обстоятельство, что нынче не делать /usr отдельным разделом смысла ровно 0.Да нет, наоборот. Усложнение, добавление лишних сущностей и точек отказа. И вы сами это доказали.
Что есть лишние сущности?
> Что есть лишние сущности?раздееееелы там, пааааапки дополнительные... там bin и там bin! там sbin и там sbin! Зачем дублировать информацию?
в openbsd это объясняется разделением на системные утилиты и установленные пользователем.
всё что из портов/пакетов - ставится в /usr
тогда даже если неправильный пакет что-то запорет, то системные утилиты останутся доступны.
в линуксах же всё из пакетов - такая логика не работает
Надо все на C:\ ? И настанет всем WinSxS.
"Следовательно, разруха не в клозетах, а в головах."
Фанат /usr/Program \files?
если /usr отдельная файловая система (или теперь это запрещено)
что будет при загрузке в однопользовательском режиме?
> если /usr отдельная файловая система (или теперь это запрещено)
> что будет при загрузке в однопользовательском режиме?systemd этого не разрешает уже давно.
Ну вот и дожили,системд не разрешает!
sys5init никто не отменял, перескочить на него с systemd не особо сложно в Дебиане
Довольно сложно, особенно, если хотим какое-нибудь DE.
> Довольно сложно, если хотим какое-нибудь DE.Если без DE то несложно.
Пользователь Debian 8.6 без systemd.
Ну, здесь я не в курсе - DE много лет нет. А так - живёт и не пищит.
>> если /usr отдельная файловая система (или теперь это запрещено)
>> что будет при загрузке в однопользовательском режиме?
> systemd этого не разрешает уже давно.Разве? Поучите матчасть.
>Разве? Поучите матчасть.Разве. Из анабиоза вылезайте. udev - часть systemd.
/usr может быть отдельной ФС, но она должна быть примонтирована initrd при загрузке перед запуском init.
Вообще-то это называется маленьким и емким словом "костыль". Жизнь есть и за пределами initramfs/systemd. Просто наш маленький программист опять накодил в сустемГ^W углу. И да, у меня есть веские основания держать /usr отдельно (и не только /usr), причем, это явно не связано с гигами на винтах. И да, с далекого 98-го initrd/initramfs нужды не вызывал. До крайних времен.
К вопросу о костылях. Напомню, что изначально /usr был тем, чем сейчас является /home, а /usr/bin-ы появились банально из-за нехватки места на первом диске.
> а /usr/bin-ы появились банально из-за нехватки места на первом диске.С тех пор было много итераций -- и сеть, и дорогие диски, и мелкие флэшки...
А ещё есть старый добрый bad block или filesystem corruption в том или ином виде. Который куда как лучше если не приводит к _полной_ неработоспособности системы (несмотря на все rescue, ipmi и т.п. -- которые когда окажутся заготовлены в нужной комбинации, а когда и нет).
Итераций было предостаточно. И именно поэтому смешно выглядит отношение к man hier как к священному писанию.fs corruption - знакомо, конечно. Во времена freebsd 4, помню, остался без /usr, вспоминал, как пользоваться ed-ом, все закончилось хорошо. Но сейчас-то эту проблему initrd решает.
> Но сейчас-то эту проблему initrd решает.Не-а.
В нормальном initrd редактора не положено. А если положен -- то здрасьте, новая итерация: новый мини-корень в initrd и /usr с ещё кучкой в довесок -- на новом корне. "Наша песня хороша, нанимай ещё индусов, начинай сначала".
За пределами initramfs жизни нет. Попробуйте, например, как нибудь загрузиться на компьютере у которого есть только накопители с последовательным доступом.
> Попробуйте, например, как нибудь загрузиться на компьютере
> у которого есть только накопители с последовательным доступом.USB?
>> Попробуйте, например, как нибудь загрузиться на компьютере
>> у которого есть только накопители с последовательным доступом.
> USB?SATA?
PS: нет, понятно, что человек про планшетный сканер... ;)
> За пределами initramfs жизни нет. Попробуйте, например, как нибудь загрузиться на компьютере
> у которого есть только накопители с последовательным доступом.Загрузиться без initrd/initramfs можно с чего угодно. Но придется утолкать модуль в ядро как встроенный. А просто потому что когда rootfs еще нет - модуль блочного устройства а потом и файлухи - будет немного не судьба. Initrd/initramfs - только один из вариантов решения этой проблемы.
> при загрузке в однопользовательском режимеА зачем?
> если /usr отдельная файловая система (или теперь это запрещено)
> что будет при загрузке в однопользовательском режиме?Так как /usr монтируется из initrd, то, при условии целостности /usr, он будет смонтирован независимо от того, однопользовательский режим или нет.
Если условие целостности не выполняется, пользователь остается в оболочке initrd, с fsck, mount, и прочими инструментами.
> Если условие целостности не выполняется, пользователь остается в оболочке initrd, с fsck,
> mount, и прочими инструментами.Что, теперь это всё в initrd пихается? А не жирно ли?
Уж лучше только в initrd, чем в /sbin и initrd одновременно.
Чем лучше? Занимает копейки, а у этих штук лишняя копия никогда не мешает. Хотя как по мне - этот initrd - адский костыль, на фиг не нужный в абсолютном большинстве случаев.
> Что, теперь это всё в initrd пихается? А не жирно ли?У меня так дебиан без всякого initrd взлетает. Just because I can.
/usr/local/{bin;sbin;lib;etc} наше всё!
У нас с Марком /bin /lib /usr отдельно. Если бы не новость, я и не поинтересовался бы. Лично мне пофиг, где оно.
> У нас с Марком /bin /lib /usr отдельно. Если бы не новость,
> я и не поинтересовался бы.Пользователям убунты стоит заглядывать в дебиановские новости - это и их будущее тоже.
Так я и заглянул и даже высказал своё (никому не нужное, конечно же) мнение. Так что, в убунте новые обои появятся, если они там переместят/перелинкуют туда-сюда? Убунта будет работать как работала, да и Демьян тоже. Это вас тут просто колбасит уже от дуновения ветра.
> У нас с Марком /bin /lib /usr отдельно. Если бы не новость,
> я и не поинтересовался бы. Лично мне пофиг, где оно.У меня для любителей желудей, которым пофиг на дубы, плохие новости!
Извини, дуб, но если к тебе пришли дровосеки - они как-нибудь обойдутся без желудей.
> Извини, дуб, но если к тебе пришли дровосекиА это ты к чему? Собрались выпилить дебиан? Так убунята регулярно заявляют про ненужность дебиана, но почему-то дальше заявлений никогда не заходит.
Или все проще и некоторые про классику "Басни Крылова: Свинья и Дуб" -- ни ухом, ни ... ?
Зря, ведь там отличная концовка:
---
Убунтуйщик также в ослепленье
Бранит дебианщиков, их достижения,
И деб-мейнтейнеров труды,
Не чувствуя, что он вкушает их плоды.
---
Дебиан с точки зрения руссификации -не паханное поле! От руководств до названия пакетов там много чего не переведено! Буду пробовать переводить.
Давай! Только "репозитОрий" - на будущее :-)
> Давай! Только "репозитОрий" - на будущее :-)а я где-то по-другому написал??? Я только в переводах открытых программ участвую, так что не мешаю никому другому(если где неправ себя)поправить!
>> руссификацииНе в обиду, но переводчику лучше сначала прокачать грамотность.
ой
Правильно написал же. "Русский"
> руссификации
> -не паханное полеОх. :(
"русификации", "непаханое".
Вы уж как-нить скооперируйтесь тогда с местным Grammar Nazi, глядишь, совместная польза получится.
собака лает, а караван идёт. Текст в переводе проверяется многократно и если что, то его и исправить можно. Это вам не здесь, на опеннете.
А что за локализация опенбокса была много лет подряд! С ошибками правописания для школьников начальных классов. Это было просто позорище! Сейчас уже с полгода-год как попрвили, наконец-то.
> А что за локализация опенбокса была много лет подряд! С ошибками правописания
> для школьников начальных классов. Это было просто позорище! Сейчас уже с полгода-год как попрвили, наконец-то.А можно узнать, что они отвечали на ваши пулл-реквесты/багрепорты или просто негодующие письма?
"Не" не всегда слитно, цитируйте правило целиком, а то он там напереводит...
Может тогда уж сделать usr симлинком на корень, что уж там...
> Может тогда уж сделать usr симлинком на корень, что уж там...Нет! Так сделано в EL7. Так в Debian-е _нельзя_!!
>Каталоги /bin, /sbin и /lib* теперь унифицированы с соответствующими каталогами внутри /usr и оформлены через символические ссылки на них. Подобная реструктуризация позволит избавиться от путаницы с размещением файлов и упростит поддержание пакетов.Одни плюсы, погляжу :)
>>Каталоги /bin, /sbin и /lib* теперь унифицированы с соответствующими каталогами внутри /usr и оформлены через символические ссылки на них. Подобная реструктуризация позволит избавиться от путаницы с размещением файлов и упростит поддержание пакетов.
> Одни плюсы, погляжу :)Просто у бедных вантузятнегов-новаторов немного крышку срывает, у них когнитивный диссонанс возникает, в аккурат, по лурку =) жаль, что срывает не дно..
Даёшь файлопомойку, складывай всё в /, зачем вообще нужны подкаталоги?
Подкаталоги для слабакой, складывайте всё в корень товарищи и всё будет просто и никакой путаницы - известно где лежит любой файл!
А оно теперь вообще способно брать с сети /usr и /home ?Ну что бы не геммороится с обслуживанием рабочих станций "условно бездисковых"?
> А оно теперь вообще способно брать с сети /usr и /home
> ?
> Ну что бы не геммороится с обслуживанием рабочих станций "условно бездисковых"?Откуда вы такие берётесь. UsrMove сделали уже лет 5 назад во всех современных дистрибутивах. Только в сабже отстают.
в современных - это в Федорином горе ?
> Откуда вы такие берётесь. UsrMove сделали уже лет 5 назад во всех
> современных дистрибутивах. Только в сабже отстают.Откуда _вы_ такие берётесь?
> UsrMove сделали уже лет 5 назад во всех современных дистрибутивах.Кто здесь?
Это где-это сделали? В каких дистрибутивах? Вы в своём Gentoo\Arch сделали? И другим не сказали? Поздравляю.
Не знаю, как насчёт арчей, а генту, как обычно пользователя не угнетает и позволяет делать, как удобно.
> А оно теперь вообще способно брать с сети /usr и /home
> ?
> Ну что бы не геммороится с обслуживанием рабочих станций "условно бездисковых"?скоро до Program Files дойдёт.
>The next release of Debian is codenamed "stretch" — no release date has been setДо первой звезды нельзя )
> В debootstrap по умолчанию задействован перенос всех исполняемых файлов и библиотек из корневых директорий в /usr.прогнулись под RedHat и systemd
Кто-то ещё кроме красной шапки делает существенный вклад в линукс? Нету разработок, а от отсутсвия оных ничего не остаётся как включать в дистрибутивы уже существующие разработки. Чё шапка пилит - то и расползается по дистрам.
> Кто-то ещё кроме красной шапки делает существенный вклад в линукс?git log в помощь. У шапки что-то типа 25% коммитов. Наверное остальные коммиты кто-то делет.
>> Кто-то ещё кроме красной шапки делает существенный вклад в линукс?
> git log в помощь. У шапки что-то типа 25% коммитов.Они последнее время опустились.
https://lwn.net/Articles/701650/
%) Ниже 10% в смысле.Не факт, что было _сильно_ больше:
https://lwn.net/Articles/555968/
https://lwn.net/Articles/395961/
https://lwn.net/Articles/275954/
https://lwn.net/Articles/222773/> Наверное остальные
> коммиты кто-то делет.
Прогнулись? А кто-то что-то делал? Не раз уже подымался вопрос, что дистрибутивы, как таковые перестали что-либо разрабатывать - все тупо перли патчи и ключи сборок с красношапки. Закономерно, что дошли до состояния, когда им прийдется копировать то что дадут - удерживать свою линию разработки уже не смогут, а отказаться от халявы - не хотят.
usrmove в мире ненадёжных носителей -- всё тот же идиотизм, происходящий из криворукости красношапых (ляпы с линковкой через /usr, которого могло ещё не быть).
> usrmove в мире ненадёжных носителей -- всё тот же идиотизм, происходящий из
> криворукости красношапых (ляпы с линковкой через /usr, которого могло ещё не быть).Холст, масло, лаптоп, read error. Потарахтев винчом btrfs обиделся и достал не читавшиеся метаданные из второй копии, невзирая на однодисковость. Иногда и DUP метаданных за RAID котируется.
> Холст, масло, лаптоп, read error. Потарахтев винчом btrfs обиделся и достал не
> читавшиеся метаданные из второй копии, невзирая на однодисковость. Иногда и DUP
> метаданных за RAID котируется.А до btrfs никто не додумывался делать дубли метаданных. Ни в ufs, ни в ext! Глупые были, что уж.
> А до btrfs никто не додумывался делать дубли метаданных. Ни в ufs,
> ни в ext! Глупые были, что уж.В btrfs чексуммы додумались пихать, чтобы еще и понимать какая из копий правильная. Хотя на самом деле додумались то еще в ZFS, но он так вроде и не умеет, что иронично.
А ext и тем более ufs вы там как-нибудь сами пользуйтесь. Можете еще снапшоты LVMом делать, если мазохизма много. Как заменять reflink - не знаю, но вы там что-нибудь придумайте. Хотя шапка вроде грозилась в XFS еще запилить. Потому что хорошая фича - энтерпрайзники, спецы по data recovery и любители запустить цать почти одинаковых виртуалок одобряют.
>> А до btrfs никто не додумывался делать дубли метаданных. Ни в ufs,
>> ни в ext! Глупые были, что уж.
> В btrfs чексуммы додумались пихать, чтобы еще и понимать какая из копий
> правильная. Хотя на самом деле додумались то еще в ZFS, но
> он так вроде и не умеет, что иронично.И как там, в криокамере?
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Chec...
http://www.sbras.ru/cgi-bin/www/unix_help/unix-man?inode+5
> #define FS_OKAY 0x7c269d38 /* superblock checksum */
> April 19, 1994.
> прочий пиар btrfs, не имеющий никакого отношения к изначальному обсуждениюА что же вы скромно умалчиваете
https://btrfs.wiki.kernel.org/index.php/Gotchas
> Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on
> HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM.Ну не придумали еще серебрянную пулю, не придумали.