FreeBSD Foundation: публикация опроса сообщества

cgroups тебе чем не угодили теперь?

Без них юзерские программы многие теперь не работают. Вернее, весь гном, init дефолтный и вообще почти всё

без vfs тоже многие юзерские программы не работают, например. Вопрос не о том был.

vfs портируется куда угодно. cgroups строго в Линукс.

так претензии к cgroups в чем?

Собери свежий fprintd где-нибудь не под Linux. ^_~

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

возможно я неправильно представляю себе профиль использования фрибсд

админство локалхоста, как еще по другому представить-то?

А ты больше читай всяких нубов которые не осилили man newfs/tunefs прочитать. Поскольку ты сам такой же нуб судя по всему, поясню: резервируется оно под нужды рута (системного администратора и важных демонов), и это настраивается от 0 до 100%, 8% это удобный дефолт.

НЁХ не совместимая ни с чем кроме популярных дистрибутивов Linux, но без которой не работают популярные OpenSource приложения.

Иксперты подтянулись.

Резервируется оно под нужды fs, а не рута, дурилка. Если ты понизишь этот резерв до <=5%, у тебя fs переключится с ‘optimization for speed’ на ‘optimization for space’, как если бы она была заполнена на >90%, начнет дико фрагментировать и работать на 1/3 от своей обычной производительности.

Никуда она не переключится, тебе только выдастся совет что с маленьким резервом разумнее оптимизировать под space (это отдельная опция которая тоже настраивается). Само по себе число этого резерва используется ровно в одном месте: при определении, разрешено ли non-root юзеру выделить ещё один фрагмент на диске, или же вернуть ENOSPC. Для рута оно вообще ни на что не влияет.

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

Ну вот тебе man, если не веришь

-m minfree
       Specify the percentage of space held back  from	normal	users;
       the  minimum  free  space threshold.  The default value used is
       8%.  Note that lowering the threshold can adversely affect per-
       formance:

       •   Settings of 5% and less force space optimization to	always
	   be  used  which will	greatly	increase the overhead for file
	   writes.

to always be used!

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

Да, признаю, тут в мане ошибка. На самом деле переключение на space optimization делается при превышении количеством фрагментированных фрагментов порога в (minfree-2)% от размера раздела. То есть принудительно оно начинает случаться если minfree<=2 (тогда порог равен нулю), а вообще может случиться и при 8%, если диск станет фрагментирован на 6%. Но ты сильно правее от этого не становишься.

И во-вторых, space optimization не означает усиление фрагментации, оно означает падение скорости записи из-за оверхедов как раз для борьбы с ней.

Т.е. у minfree есть скрытая функция: (minfree-2)% это лимит фрагментированности диска, после которого драйвер файловой системы начинает активно с ней бороться.

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

sys/ufs/ffs/ffs_alloc.c - тут поиском ищешь все вхождения fs_minfree и fs_optim (часть из них комментарии, часть - лимиты для не-рута, и ещё два - то самое автопереключение режима оптимизации, код там несколько строк всего).

Можешь поискать то же самое по всему ядру (sys/) чтобы убедиться что в других файлах не надо смотреть.

не присутствие чего-то, а отсутствие чего-то

Не все страдают от ОКР

В коде разбираться лень, но вот такое там увидел:

case FS_OPTSPACE:
	request = nsize;
	if (fs->fs_minfree <= 5 || ...)
		break;
        log(LOG_NOTICE, "%s: optimization changed from SPACE to TIME\n", fs->fs_fsmnt);
	fs->fs_optim = FS_OPTTIME;
	break;

ЧТД. Если <=5%, перехода на оптимизацию по времени не будет. Весь код не читал, но тут это хорошо видно.

Про фрагментацию, скорее всего, тоже брэшэшь.

Это случай когда ты поставил -o space а ядро переключает на время. Чуть ниже вторая ветка, которая переключает -o time на -o space - речь про неё.

Про фрагментацию, скорее всего, тоже брэшэшь.

Да нет, это ты продолжаешь позориться.

Мне в этом разбираться лень, но ты же зарепортишь баг, что в мане ошибка и знающие люди исправят?

Изначально речь шла про самую распространённую игровую ОС. Тут немного не понятно что подразумевается под самой распространённой. Если речь про ОС на самой продаваемой консоли, то внезапно это Linux, потому что на 2й плойке трудился именно он. Если речь про актуальное консольное поколение, то на соответствующей странице пс5 я не вижу никаких упоминаний BSD.

Потому же, почему наезжают на win32 gui. Потому что «стильно-модно-молодёжно».

Разве это можно назвать вендорлоком? Linux это ядро, не вендор. Вендор это RedHat, Canonical.. Разве нет?

Не знаю что там за проблемы с fprintd, у меня нет устройств, на которых можно протестировать. К тому же это open source. На странице написано, что поддерживается проектом не только Linux, но и другие свободные юниксы. Так что если в условной FreeBSD что-то не работает – можно создать issue, а ещё лучше патч закинуть.

Ладно, я посмотрел детальнее, ман почти прав. То есть прнудительного переключения по minfree<=5, как в нём написано, конечно нет, но в целом работа этого переключателя рассчитана на регулярное переключение туда и обратно (накопились фрагменты - переключаемся на space и устраняем их, как их стало меньше - переклчаемся на time и они опять копятся), и при minfree<=5 первое переключение рано или поздно сработает, а вот второе уже нет.

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

От cgroups несёт костылями за километр.

Потому что это единственная(!) файловая система, готовая к БЕШЕНЫМ нагрузкам.

На проц и память пользователя этой системы?

В Ubuntu галочку при установке сделали, или там чет не так?

Разве это можно назвать вендорлоком? Linux это ядро, не вендор. Вендор это RedHat, Canonical.. Разве нет?

Сути это не меняет.

К тому же это open source. На странице написано, что поддерживается проектом не только Linux, но и другие свободные юниксы. Так что если в условной FreeBSD что-то не работает – можно создать issue, а ещё лучше патч закинуть.

Этому fprintd со свежих версий требуется (обязательно и безальтернативно) journald в рантайме, с которым он хочет линковаться. Опции отключить его на этапе сборки нет, патчить там надо половину кода, чтобы вернуть старый добрый logger и вряд ли это примут, потому что проект находится под GNOME, а эти первыми легли под systemd.

это всё не имеет отношения к твоему изначальному заявлению о том, что ufs что-то там неисправимо резервирует

неисправимо резервирует

А я и не заявлял такого. Я писал, что резервирует [по дефолту], что оно с успехом и делает. А если человек нуб типа меня, то оно так и остается навсегда. Я ведь даже зная о существовании tunefs, все равно эту переменную трогать не стал бы ибо опыт с BSD в целом и FreeBSD в частности, подсказывает, что себе дороже.

Странный у тебя опыт, у меня противоположный. Убирать этот резерв на системных разделах (/ /usr /var /tmp) и правда не стоит - именно потому что тогда кто-то может сожрать всё место и руту его не останется (впрочем, ssh от этого не сломается). А на дисках для данных можно смело ставить -m0 без вредных последствий. Ну, разве что небуферизованная запись мелкими блоками станет чуть медленнее из-за описанного алгоритма противодействия фрагментации. Но лучше всё-таки оставить -m8 - тогда, когда тебе вдруг неожиданно напишется, что места больше нет, тебе не придётся срочно бежать в магаз за новым, а можно будет всего лишь сделать -m0 и работать дальше, а новый покупать уже не торопясь.

потому что проект находится под GNOME

Так это первое что надо фиксить, по-моему.

нет systemd, нет udevd, нет wayland, нет Rust’а в ядре

К этому списку неплохо бы добавить: нет glibc, нет gnu coreutils, нет pulseaudio. К счастью, я сижу на Alpine, единственный адекватный дистрибутив сейчас, там только musl, busybox и mdev. Вот если и он загнется, то уже и я подумаю уползать.

нет systemd, нет udevd, нет wayland, нет Rust’а в ядре

как тут не вспомнить Петросяна в начале 90-х:

- Богатая у нас страна! Чего у нас только нет!
- Ну да, жратвы нет, порядка нет, электроники нет, денег нет..

чо там есть во фре то, если там и нет ничего из нормального?

Сути это не меняет.

Я всё ещё не вижу вендорлока. Обычно вендорлок связывают с чем-то пропритарным и закрытым, что очевидно не применимо к линуксу. Иногда накопленную крупную кодовую базу называют вендорлоком. Мол столько всего на эту кодовую базу завязано, что разработчикам какой-нибудь программы потребуется куча времени и денег для того чтобы перелезть на другую кодовую базу. Но тогда получается, что мы просто окружены на каждом шагу вендорлоками, и open source «вендорлок» выглядит самым безобидным. В конце концов, всё зависит от глобальности проблемы. Пока терпеть «вендорлок» выгоднее чем перелазить, так и будет. Вот у разработчиков xorg терпение лопнуло и пошли пилить wayland. И, не смотря на критику из каждой подворотни, почему-то появилась куча композиторов с реализацией wayland. А xorg как был, по сути, единственной живой реализацией X11, так теперь и останется. Так что всё в ваших руках :)

Какие претензии к coreutils?

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

ещё две с половиной есть в линуксе - это ext2/3/4. Всё остальное - экзотика

Ты начисто забыл об XFS. Её тоже очень часто применяют, особенно на RHEL и клонах.

А вот ext2 и ext3 сейчас можно только на всяких старых серверах встретить с древними Linux.

Поделись травойметодом подсчета. Про первые три позиции вопросов нет, а вот дальше я не понял.

для ноутбуков

Как там обстоят дела с S4?

Нет не забыл, и вполне сознательно отнёс её ко второй категории. То что шапка хочет экзотику делать дефолтом это её дело. Точно так же zfs дефолт в солярисе, но он от этого обычной фс не становится. (если что, из этого не следует что солярис с шапкой похожи, первый уважаем намного больше).

А вот ext2 и ext3 сейчас можно только на всяких старых серверах встретить с древними Linux.

Я бы написал какое-то общее название для ext2/3/4 но его нет, поэтому перечислил. Уделять особое внимание какой-то из вариаций дефолтной линуксовой фс я не планировал и в дискуссии об их популярности вдаваться не хочу. Речь вообще не про популярность а про внутреннее устройство.

Ты так говоришь про RHEL, как будто он какой-то маргинальный дистрибутив. Что мягко выражаясь не так, Ubuntu и Debian на серверах в целом его опережают, но на крупных предприятиях он (или клоны) стандарт по сей день.

Плохо. Предлагается использовать S3.

Я ж написал, что вообще не касался вопроса популярности. Речь была про техническую организацию файловой системы. Есть традиционная - с порезанными на секции разделом, в каждой из которых есть сколько-то инод и сколько-то блоков для данных, ну итд. Так работали традиционные фс в юниксе, их наследник ufs2 в фрибсд и ими же вдохновлённые ext2/3/4. И есть другие файловые системы, которые от этой схемы ради каких-то целей отходят. Вот эти самые цели, ради которых придумываются альтернативные схемы хранения, рядовым юзерам обычно не требуются.

Ну я бы не сказал, например reflink может быть очень полезен. Скажем, ты редактируешь за много подходов крупное видео, и каждый раз сохраняешь промежуточный результат — на ext4 занятого места будет куда больше, чем на XFS или btrfs.

Поддержка сканеров отпечатков пальцев нужна почти никому.

вендорлок связывают с чем-то пропритарным и закрытым

А тут оно открыто, но прибито гвоздями. Потому что systemd использует специфичные только для ядра Linux фичи. Да, никто и не обещал переносимость самого systemd, но разработчики софта привязывают свой код к systemd, тем самым полностью лишаясь переносимости.

Ну ладно, возможно я неправильно представляю себе профиль использования фрибсд.

Вот и для меня было бы интересно, а какой основной профиль использования у неё сейчас?

Ну, я тоже за переносимость софта всеми руками. По какой-то причине разрабы решили линкануться с куском systemd. Наверное, так им показалось удобней, не разбирался. Но кому это будет мешать, сможет вырезать привязку или заслать патч, который добавит опции сборки без линковки с systemd.