Релиз дистрибутива Fedora 17 (и RFRemix 17)

[diesel]

у закрыто-несвободного софта по определению нет открытых (и тем паче свободных) исходников.
но здесь речь идёт не о hello.c, и даже не о desktop environment.
дальше-то что делать с этим, «форкнутым»?

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

[Aviator]

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

С удовольствием, но если это всё начать рассказывать, то это не на один час, даже самых общих чертах. Иначе просто вам будет непонятно. Это материал нескольких книг, по-хорошему. Вот только тогда станет ясно, как и, главное, почему так сделали. А "ломать устои", переписывать стандарты, может каждый. Только это не признак большого интеллекта и "крутого хакера" (в хорошем смысле этого слова).

[sgfault]

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

но если это всё начать рассказывать, то это не на один час, даже самых общих чертах.

Аа, ну да, это все объясняет.

Иначе просто вам будет непонятно.

Непонятно кому? Неспециалисту? Ну так в чем проблема, объясните коротко, но понятно только для специалистов. Уверен, тут такие найдутся.

А "ломать устои", переписывать стандарты, может каждый.

И у многих это получается, сломать и переписать? Вот у Поттеринга, вижу, получается. Еще кто-нибудь?

[Aviator]

Непонятно кому? Неспециалисту? Ну так в чем проблема, объясните коротко, но понятно только для специалистов. Уверен, тут такие найдутся.

Поясню на тривиальных примерах. Например, пространства данных таблиц и индексов разносятся по отдельным томам, на разных группах физических носителей. Что есть защищённые системы, где /boot, /usr и ряд других ветвей ФС, находится на устройстве, который обычными средствами допускает только чтение. Вы спросите, а почему, а зачем, ведь и когда всё одним куском прекрасно работает?
Попытаюсь вам объяснить про иерархию корня:

Иерархия файловых систем в *NIX строится с учётом особенностей файловых систем, физических носителей и характера работы ОС с ними.
/bin, /boot, /lib, /sbin, /usr содержат редко меняющиеся файлы, слабо фрагментируются.
При этом /boot, /bin, /lib и /sbin должны быть гарантированно доступны даже в том случае, если произошла авария в системе. Эти каталоги содержат в том числе средства для анализа сбоя и восстановления системы. Вместе со служебными каталогами /dev, /proc и не так давно /sys (в linux) это был минимальный набор, чтобы стартовать систему и разобраться, что же ж произошло.
/usr содержит остальные компоненты операционной системы, /usr/local всё то, что установлено мимо пакетного менеджера. Эту иерархию традиционно выносили в отдельный том, даже в обычных условиях недоступный для записи. Этот том слабо фрагментируется (только при обновлениях).
/var наоборот использовался для размещения очень часто меняющихся файлов, соответственно к файловой системе этого тома предъявляются немного другие требования. Кроме того, в иерархии /var могут присутствовать ещё и тома, используемые для хранения больших объёмов данных пользовательских программ. Основной критерий тут - быстрый доступ и устойчивая к фрагментации ФС.
/var/log тоже находился, фактически, на отдельном носителе для того, чтобы в случае аварии была возможность проанализировать файлы протоколов. Кроме того, очень часто /var/log размещают на файловой системе и носителе, которые физически не удаляют данные, только дописывают.

Таким образом, загрузчиком из /boot подтягивался образ ядра, загружался, ядром монтировался / и запускался init, Который подготавливал, в первую очередь минимальное рабочее окружение. Затем монтировались остальные иерархии файловой системы (не сеть!) и только после этого начиналась загрузка служб. После инициализации сети монтировались сетевые файловые системы. Последовательная загрузка служб обеспечивала всегда чёткую локализацию проблемы при загрузке. Мы можем построить такую систему, в которой невозможно, без физического вмешательства (переключить перемычку разрешения записи, например) нельзя изменить системные файлы. В которой для каждой задачи хранения данных (/usr и /var, например) используется наиболее подходящая для этого файловая система.

С появлением SSD, которые гораздо сильнее ограничены в циклах записи, возможность вынести /usr, /var, /var/log и прочие на различные носители опять очень востребована. Дело в том, что если выйдет из строя SSD с логами, то он во первых традиционно дешевле, меньше. Во вторых не пострадает сама система.

И в том же духе.

И у многих это получается, сломать и переписать? Вот у Поттеринга, вижу, получается. Еще кто-нибудь?

Ломать не строить. Пока я не вижу ни одного проекта Поттеринга, который был бы лучше того, что он "поломал". А лучше, не "ломать", а улучшать, вычищать код, делать его понятнее и документированнее.

[Warderer]

Иначе просто вам будет непонятно.

Непонятно кому? Неспециалисту? Ну так в чем проблема, объясните коротко, но понятно только для специалистов. Уверен, тут такие найдутся.

Специалисты просто давно в курсе. Держат /usr на отдельном от / разделе, с файловой системой, наиболее подходящей в его, частном случае. Как и /var, как и /var/log и ещё много нужных вещей, о которых "обычные домашние пользователи" не задумываются. Потому как у них зарплата напрямую зависит от таких странных параметров как "коэффициент доступности ресурса", "время реакции на запрос". Давно и вдумчиво прочитали треды и на ЛОРе и на опеннете.

А "ломать устои", переписывать стандарты, может каждый.

И у многих это получается, сломать и переписать? Вот у Поттеринга, вижу, получается. Еще кто-нибудь?

Сломать - согласен. Переписать - тоже. Это как оторвать у куклы руки/ноги головы и заново пришить в произвольном порядке.

[TuxWare]

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

И эта система будет Android, Mac или Windows. И ничего не нужно форкать. Уже все давно форкнуто.

[Warderer]

Aviator
Синхронно, однако, ответили. :)

[sgfault]

Aviator, то, что вы написали, - просто пересказ FHS. Уточню на всякий случай: я не пользуюсь ни Федорой, ни systemd, - и, я вам напомню, что в новости изначально было вот что:

перенос корневых каталогов файловой системы /lib, /lib64, /bin и /sbin в /usr;

поэтому /var, /var/log и даже /usr/local тут вообще не при чем. Дальше мои ответы будут взяты из ссылки, которую дал Vascom.

При этом /boot, /bin, /lib и /sbin должны быть гарантированно доступны даже в том случае, если произошла авария в системе. Эти каталоги содержат в том числе средства для анализа сбоя и восстановления системы. Вместе со служебными каталогами /dev, /proc и не так давно /sys (в linux) это был минимальный набор, чтобы стартовать систему и разобраться, что же ж произошло.

Почему не использовать для этого initrd?

Myth #9: The /usr split is useful to have a minimal rescue system on the root file system, and the rest of the OS on /usr.

Fact: On Fedora the root directory contains ~450MB already. This hasn't been minimal since a long time, and due to today's complex storage and networking technologies it's unrealistic to ever reduce this again. In fact, since the introduction of initrds to Linux the initrd took over the role as minimal rescue system that requires only a working boot loader to be started, but not a full file system.

Таким образом, загрузчиком из /boot подтягивался образ ядра, загружался, ядром монтировался / и запускался init, Который подготавливал, в первую очередь минимальное рабочее окружение.

Все это может сделать initrd. В случае с initrd изменения при объединении /bin.. в /usr будут минимальны:

Myth #8: The /usr merge will break my old installation which has /usr on a separate partition.

Fact: This is perfectly well supported, and one of the reasons we are actually doing this is to make placing /usr of a separate partition more thorough. What changes is simply that you need to boot with an initrd that mounts /usr before jumping into the root file system. Most distributions rely on initrds anyway, so effectively little changes.

Затем монтировались остальные иерархии файловой системы (не сеть!) и только после этого начиналась загрузка служб. После инициализации сети монтировались сетевые файловые системы. Последовательная загрузка служб обеспечивала всегда чёткую локализацию проблемы при загрузке. Мы можем построить такую систему, в которой невозможно, без физического вмешательства (переключить перемычку разрешения записи, например) нельзя изменить системные файлы. В которой для каждой задачи хранения данных (/usr и /var, например) используется наиболее подходящая для этого файловая система.

С появлением SSD, которые гораздо сильнее ограничены в циклах записи, возможность вынести /usr, /var, /var/log и прочие на различные носители опять очень востребована. Дело в том, что если выйдет из строя SSD с логами, то он во первых традиционно дешевле, меньше. Во вторых не пострадает сама система.

Говорят, "монтировать в ro" и "/usr на отдельном разделе" можно и нужно:

Myth #7: After the /usr merge one can no longer mount /usr read-only, as it is common usage in many areas.

Fact: Au contraire! One of the reasons we are actually doing this is to make a read-only /usr more thorough: the entire vendor-supplied OS resources can be made read-only, i.e. all of what traditionally was stored in /bin, /sbin, /lib on top of what is already in /usr.

А вот байка (из той же ссылки) про разделенные /bin,.. и /usr Understanding the bin, sbin, usr/bin , usr/sbin split.

Что касается systemd, говорят, он не имеет никакого отношения к обсуждаемому объединение /usr:

1. It isn't systemd's fault. systemd works fine with /usr on a separate file system that is not pre-mounted at boot.

Ну, а на остальные вопросы про syetemd, уверен, вам ответит diesel

[Bizdelnick]

Почему не использовать для этого initrd?

Да-да, давайте сделаем initrd в пол-гига.
Где-то рядом давали ссылку про то, как увеличить скорость загрузки. Там некто рекомендовал вообще не делать initrd. Кто же это был, никак не припомню...

Что касается systemd, говорят, он не имеет никакого отношения к обсуждаемому объединение /usr:

Конечно, он тут ни при чём. Загрузка сама по себе поломалась.

[sgfault]

Почему не использовать для этого initrd?

Да-да, давайте сделаем initrd в пол-гига.

В чем разница: смонтировать для восстановления из initrd корневой раздел на пол-гига или /usr на 10 гигов? Или вообще внешний или сетевой диск?

Где-то рядом давали ссылку про то, как увеличить скорость загрузки. Там некто рекомендовал вообще не делать initrd. Кто же это был, никак не припомню...

Ээ.. это вы на меня намекаете что ли? Хм, я такого тоже не помню. Дайте ссылку, а то интересно ведь кто же это был.

Что касается systemd, говорят, он не имеет никакого отношения к обсуждаемому объединение /usr:

Конечно, он тут ни при чём. Загрузка сама по себе поломалась.

Я только разместил объяву сказал, что так говорят и привел ссылку. Если вы посмотрели, то там приводится также список других программ, которые не работают без /usr:

Most of the failures you will experience with /usr split off and not pre-mounted in the initramfs are graceful failures: they won't become directly visible, however certain features become unavailable due to these failures. Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware that currently they are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.

You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* -- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases.

Что касается сломанной загрузки, - еще раз, в новости шла речь об объединении /bin.. в /usr, а даже не о systemd. Или, может, вы хотите сказать, что по приведенным ссылкам написана _неправильная_ информация? В таком случае, вам следует рассмотреть вариант редактирования этих статей, чтобы такие далекие от всего этого люди, как я, читали правильную информацию.

[Bizdelnick]

это вы на меня намекаете что ли?

Ни в коем разе!
[NIXP] Представлен новый демон печати для Linux — printerd

[alv]

Кто же это был, никак не припомню...

Самозванец это был, и даже без гитары.

Однажды Гоголь переоделся Пушкиным, пришёл к Державину и сказал, что не нужно делать initrd.
А Державин подумал, что это и в самом деле Пущкин и, сходя в гроб, initrd не сделал. Оттого и помер.

(с) Даниил Хармс

[alv]

по приведенным ссылкам написана _неправильная_ информация?

А что, Вы впервые сталкиваетесь с тем, что в интернете бывает неправильная информация?

вам следует рассмотреть вариант редактирования этих статей

Инетерсно, почему кто-то должен редактировать некоего автора? Да ещё забесплатно
Только ради того,

чтобы такие далекие от всего этого люди, как я, читали правильную информацию.

А кто Вам запрещает читать правильную информацию? Интернет большой. И информации, противоречащей данной, в нём как минимум не меньше.
Не ищется?
Вот нашли же как-то баянище

про разделенные /bin,..

которое я слышал лет 15 назад (и которое тогда уже было баяном).
Но при этом забывают, что когда этот баян был ещё маленькой детской гармошкой, это была шутка.
Как и то, что Керниган придумал UNIX потому, что ему вдруг очень захотелось поиграть в "Звёздные войны".
Просто в старое время /usr был тем, чем сейчас является /home - на что толсто намекает его название. Просто всеми users той машины были программисты, и их пользовательские данные были их программами, а не музыкой, фильмами и парнухой, как нынче.

[diesel]

Иерархия файловых систем в *NIX строится с учётом особенностей файловых систем, физических носителей и характера работы ОС с ними.

Это Вы сами придумали, или подсказал кто? Вы забываете о нескольких вещах: во-первых, как правильно подсказали по ссылке, по которой никто не ходит Fedora 17 - это далеко не первая *nix система, которая все перенсла в /usr. Во-вторых, иерархия файловых систем в *nix'ах не может строится на особенностях "физических" файловых систем(а-ля ext2, jfs, etc), потому что *nix системы не ограничены linux, и, как ни странно, большАя часть *nix систем, за пределами linux-мира, ставится и загружается с одной-двух файловых систем. Про физические носители вообще смешно, если бы иерархия ФС учитывала особенности физических носителей, то стоило бы ожидать кардинальных изменений при появлении новых физических носителей. Кардинальных изменений нет.

Вообще все с точностью до наоборот. Ирархия файловой системы в *nix'ах построена с учетом функционального назначения файлов. Бинарники - в одной папке, библиотеки - в другой, логи - в третьей. И иногда этот подход оказывается удобным в оптимизации, когда одно можно смонтировать рид-онли, другое поместить в память, и так далее. Не надо путать следствие с причинами.

/bin, /boot, /lib, /sbin, /usr содержат редко меняющиеся файлы, слабо фрагментируются.
При этом /boot, /bin, /lib и /sbin должны быть гарантированно доступны даже в том случае, если произошла авария в системе. Эти каталоги содержат в том числе средства для анализа сбоя и восстановления системы. Вместе со служебными каталогами /dev, /proc и не так давно /sys (в linux) это был минимальный набор, чтобы стартовать систему и разобраться, что же ж произошло.
/usr содержит остальные компоненты операционной системы, /usr/local всё то, что установлено мимо пакетного менеджера. Эту иерархию традиционно выносили в отдельный том, даже в обычных условиях недоступный для записи. Этот том слабо фрагментируется (только при обновлениях)

Во-первых, /bin, /boot, /lib, /sbin и /usr содержат редко меняющиеся файлы, при этом, первые четыре, если Вам верить офигенно критичны. При этом не сильно критичный /usr "защищают" RO-монтированием, а все остальные... в пролете? Как-то нелогично. Тем более что "сбой" можно устроить, абсолютно случайно, например, удалив какую-нить из этих папок Ошибки случаются, я, например, когда-то сделал mv /* /lib/ - не смертельно, но неприятно. А chmod'ы, chown'ы корня - вообще в порядке вещей Не странно ли полагаться на эти папки, как 100% доступные при сбое? Монтировать корень в RO? - тогда это никакого принципиального отличия не имеет, если эти папки - симлинки. И, как ни странно, но вот как раз вариант: /boot - отдельный RO раздел, в нем initrd, в котором есть те самые "средства для анализа и восстановления" - гораздо более здравый вариант, с точки зрения гарантий.

Во-вторых, это вы еще про кластера баз данных, или уже спустились с небес на землю? Потому как чем больше у вас "однотипных" *nix систем, которые занимаются одним и тем же, тем более вероятно что вам по большому счету пофигу на все эти папки и то что в них лежит. Логи вы будете читать по-другому. Логи полезных сервисов вы скорее всего не будете хранить в /var/logs. "Полезные сервисы", сами по себе, тоже скорее всего будут работать вне стандартной иерархии. А если эта дрянь упадет, самым быстрым и правильным вариантом восстановления, если сервер не в состоянии перезагрузится, будет... переустановка, вернее даже сказать восстановление с образа. Да, это сильно отличается от варианта "поднять упавшее с помощью /bin, /boot и /sbin".

/var наоборот использовался для размещения очень часто меняющихся файлов, соответственно к файловой системе этого тома предъявляются немного другие требования. Кроме того, в иерархии /var могут присутствовать ещё и тома, используемые для хранения больших объёмов данных пользовательских программ. Основной критерий тут - быстрый доступ и устойчивая к фрагментации ФС.
/var/log тоже находился, фактически, на отдельном носителе для того, чтобы в случае аварии была возможность проанализировать файлы протоколов. Кроме того, очень часто /var/log размещают на файловой системе и носителе, которые физически не удаляют данные, только дописывают.

Знаете почему на самом деле полезно выносить /var, в том числе и /var/log в отдельное место? - под систему редко отдают много места, с учетом того что еще принято отделять /usr, то корень будет совсем маленьким, и когда /var вдруг неожиданно наполнится логами или еще чем, у вас корень будет забит под завязку, и это очень неприятная ситуация. По той же причине отдельно выделяют /tmp. Остальное - иллюзии или полезные бонусы, как получиться.

Кроме того, очень часто /var/log размещают на файловой системе и носителе, которые физически не удаляют данные, только дописывают.

а логротейт сходит с ума ) да-да ) все так и просиходит. пишите еще

[diesel]

Что касается systemd, говорят, он не имеет никакого отношения к обсуждаемому объединение /usr:

Конечно, он тут ни при чём. Загрузка сама по себе поломалась.

Загрузка не то что не ломалась. Загрузкой в федоре занимаются вполне серьезно.

[altwazar]

Запомните, линукс не только на десктопах и линукс это не только Fedora и на ней свет клином не сошелся. Я, например, считаю, что Fedora, один из самых худших дистрибутивов для обычного пользователя.

Оказывается в красной шляпе о существовании серверов не вкурсе, жду следующих откровений.
А всего то собираются убрать древний нелепый костыль, в котором уже давно нет необходимости.

[Aviator]

Кроме того, очень часто /var/log размещают на файловой системе и носителе, которые физически не удаляют данные, только дописывают.

а логротейт сходит с ума ) да-да ) все так и просиходит. пишите еще

Мистер всезнайка, это делают для того, чтобы после успешной атаки логи не были бы затёрты. И logrotate в этом случае не при делах.

[Vascom]

Вот видишь, улучшит. И для платной техподдержки

википедия://сарказм

Вы так говорите, будто платная техподдержка это что-то плохое.

[taaroa]

Оказывается в красной шляпе о существовании серверов не вкурсе, жду следующих откровений.

оказывается, в реальном мире, rhel и его производные используют либо «древний» sysv init, либо upstart. жду следующих откровений.

p.s. напоминает философию уличной драки: главное начать, а там видно будет, куда-то да «вывезет».

[Vascom]

Иначе просто вам будет непонятно.

Непонятно кому? Неспециалисту? Ну так в чем проблема, объясните коротко, но понятно только для специалистов. Уверен, тут такие найдутся.

Специалисты просто давно в курсе. Держат /usr на отдельном от / разделе, с файловой системой, наиболее подходящей в его, частном случае. Как и /var, как и /var/log и ещё много нужных вещей, о которых "обычные домашние пользователи" не задумываются. Потому как у них зарплата напрямую зависит от таких странных параметров как "коэффициент доступности ресурса", "время реакции на запрос". Давно и вдумчиво прочитали треды и на ЛОРе и на опеннете.

А "ломать устои", переписывать стандарты, может каждый.

И у многих это получается, сломать и переписать? Вот у Поттеринга, вижу, получается. Еще кто-нибудь?

Сломать - согласен. Переписать - тоже. Это как оторвать у куклы руки/ноги головы и заново пришить в произвольном порядке.

Ну так обсуждаемый перенос каталогов позволяет и даже делает удобнее использование /usr на отдельном разделе! И по сети тоже.
Я же говорю, вы не ходили по ссылке и не читали что там написано.

[Aviator]

А вообще, давайте, поощряйте эти "революции" дальше. Я, лично, ничего не имею против. Просто пытаюсь донести к чему это приведёт.
Хотите вместо нормального конструктора получить "лего" в котором все кубики уже собраны и проклеены дихлорэтаном - пожалуйста.
Мне, если честно, уже пофиг.
Я уже успел застать 2 такие "революции" (и 1 на своей шкуре), и увидеть к чему это приводит. Поэтому участвовать в них не вижу смысла.

Удачи.

[Vascom]

Согласен. Вроде бы все всё поняли.
Давайте просто посмотрим что будет дальше, к чему это приведёт.

Так и хочется сделать прогноз, но удержусь

[alv]

Вы так говорите, будто платная техподдержка это что-то плохое.

Ничего плохого, но...
Диалог вспомнился, из бессметрного фильма:

- Аполитично рассуждаешь, товарищ Джабраил! Двадцать пять баранов, в то время как наш район ещё не полностью расчитался с государством по шерсти и мясу
- А ты не путай свою личную шерсть с государственной
- А я, между прочим, товарищ Джарбраил, для того сюда и поставлен, чтобы блюсти государственные интересы.

Так что давайте не путать личную шерсть бизнеса на техподдержке с интересами всего прогрессивного человечества. Я, конечно, понимаю, что товарищ Vascom для того сюда и поставлен, чтобы блюсти государственные интересы.
Но и Вы должны понимать, что многих из здесь присутствующих эти интересы интересны до поры, до времени.
Так что будь готовы получать свою порцию сарказма.
Как её не так давно сполна получали представители РОСы - за её личную шерсть

[Vascom]

Я ни кем сюда не поставлен. И за свою техподдержку денег не получаю (хотя было бы неплохо).
Но и мне видится гораздо более удобным помогать всем вне зависимости от дистрибутива, если у них будет одинаковая удобная структура каталогов. А то жалуются, это не работает, то не работает... выясняю, ищу, а оказывается в его "прекрасном самосборном дистрибутивчике" всё нестандартно, не как в апстриме.

Хочу ещё добавить, что RedHat не пытается выделиться, она просто и есть upstream.
Уж не знаю почему, но многим не нравится само слово RedHat и любые её инициативы. Правильно тут кто-то заметил, что сделал бы это Марк в Убунту и все рукоплескали бы.

Ну что, продолжаем дальше, до 6 страниц догоним хотя бы?

[taaroa]

Я ни кем сюда не поставлен. И за свою техподдержку денег не получаю (хотя было бы неплохо).

а какое отношение к проекту fedora имеет рашнфедора вообще?
https://www.linux.org.ru/news/redhat/777176...comment-7825827 и далее по ссылкам.

выясняю, ищу, а оказывается в его "прекрасном самосборном дистрибутивчике" всё нестандартно, не как в апстриме.

толпы гентушников и арчеводов ждут ващей помощи, просто приступом берут ваш форумок и не мыслят жизни своей без вашей прекрасной wiki.
весьма познавательно, пишите ещё!

[altwazar]

Правильно тут кто-то заметил, что сделал бы это Марк в Убунту и все рукоплескали бы.

"Ему надоело переставлять кнопочки, взялся за директории."
"Все больше пытаются отдалиться от апстрима."
"Ubuntu уже не linux".
Т.е. та же ересь, только в профиль.

[Vascom]

Да, больше ада, давайте неадекватного Джерома сюда позовём. Давайте вспомним как уходил мегакрутой Sergem, который на пустом месте костыли лепил, вместо исправления апстрима. Слушайте больше сказок. И ссылок на ЛОР побольше пишите.
Вот вам мой ответ https://www.linux.org.ru/news/redhat/777176...comment-7821909

Рашнфедора имеет прямое и непосредственное отношение к Fedora, является её частью.

Кстати, про Джерома. Вы читаете рассылку переводчиков Федоры? Джером там себя большим неадекватом показал. Именно после этого он стал ставить копирайты на свои статьи на лоре, чтобы не дай бог мы ими не воспользовались. Так что не надо на него ссылаться.

выясняю, ищу, а оказывается в его "прекрасном самосборном дистрибутивчике" всё нестандартно, не как в апстриме.

толпы гентушников и арчеводов ждут ващей помощи, просто приступом берут ваш форумок и не мыслят жизни своей без вашей прекрасной wiki.
весьма познавательно, пишите ещё!

А при чём тут эти детишки? Речь же о серьёзных дистрибутивах идёт.

[Aviator]

Хочу ещё добавить, что RedHat не пытается выделиться, она просто и есть upstream.
Уж не знаю почему, но многим не нравится само слово RedHat и любые её инициативы. Правильно тут кто-то заметил, что сделал бы это Марк в Убунту и все рукоплескали бы.

Ни RedHat ни Canonical не являются upstream для всего GNU/Linux. Первые да, делают попытки понатыкать своих граблей везде где можно и стать upstream-во-всём.
Вторые пересказывают Debian (пока получается как арии Корузо в исполнении Рабиновича). Кстати, много людей, начиная с *buntu, в итоге, переезжают на Debian.
Кроме того, по моему мнению, солидарному с мнением моих товарищей, наибольшие проблемы возникают с дистрибутивами со словом "Enterprise" в названии и производных от них.
"Маленькие самосборные дистрибутивы", как правило, редко отличаются от upstream программ, входящих в них. Так что с ними всё просто и человек, собравший его, как правило грамотнее и в состоянии внятно объяснить свои проблемы и то, как он что делал.

[alv]

А при чём тут эти детишки? Речь же о серьёзных дистрибутивах идёт.

После такого заявления дискутировать больше не о чем.
Добавлю только, что всё это сильно напоминает присноблаженную Linux XP.
О которой Вы, конечно, слыхом не слыхивали, да?

[diesel]

Кроме того, очень часто /var/log размещают на файловой системе и носителе, которые физически не удаляют данные, только дописывают.

а логротейт сходит с ума ) да-да ) все так и просиходит. пишите еще

Мистер всезнайка, это делают для того, чтобы после успешной атаки логи не были бы затёрты. И logrotate в этом случае не при делах.

все смешалось в доме Облонских... теперь сервера у нас не только падают, их еще и атакуют Про то чем симлинки /bin, /lib и /sbin мешают при этих всех странных построениях вы все-таки расскажите? А то чем больше построений, тем, как я уже писал, все более и более пофигу на то где и чего там в системе есть