а, по-моему, бредовая идея сваливать всё в кучу.

Дело не в конкретном действии, а в твоих навыках.

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

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

Я не хочу тебя или кого-то упрекать в владении или не владении каким-то навыком, просто пойми, что компиляция ядра - это не «не чем заняться» и не «фанат», это просто легко. Для некоторых.

Хорошо, процентов на 15% троллю

Да нет, процентов на 90%.

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

Ценность Линукс (была) в универсальности: взяв книгу, например, «Линукс для профессионалов» или любую другую, я могу применить знания оттуда к любому дистру. Сейчас Линукс удаляется от этой приятной особенности, и объединение каталогов - пример из того, что этому способствует...

Дистрибутивы, которые ничем не отличаются, нахрен не нужны. При этом под «отличаются» я имею ввиду не дефолтный гуй и тему оформления.

И если бы ты прочитал до конца хоть одну книгу «для профессионалов», то знал бы, что local-site программы, не управляемые пакетным менеджером, в линуксах складываются в /usr/local, либо в /opt и не рассказывал бы сейчас эти истории про свою помойку в /usr/{bin,sbin,lib}

А если я хочу, чтобы и другие пользователи имели возможность запускать этот софт?

/opt

/home однозначно с noexec чтобы хернёй не страдали

./automake.sh && ./configure тоже будешь в /usr/local запускать? :-D

Чувак, ты вообще хоть что-нибудь про разработку софта знаешь?

нет никаких глюков

Основные глюки systemd связаны с его уродским журналом. И я думаю, глючить оно будет еще долго.

А в остальном согласен, в области своего применения Арч вполне KISS и работает без нареканий.

Офигительно

fallback - это все модули.

если бы ты прочитал до конца хоть одну книгу «для профессионалов», то знал бы, что local-site программы, не управляемые пакетным менеджером, в линуксах складываются в /usr/local, либо в /opt

Не «не управляемые пакетным менеджером», а «не входящие в дистрибутив».

Ты не в теме. Иди кури матчасть.

где-то натыкался на цитату

И твой аффтар тоже не в теме.

неагрументированного, но массового недовольства большинства.

В общем, советую задуматься)

Ты же понимаешь, что задумываться никто не будет? ;-)

local-site программы, не управляемые пакетным менеджером, в линуксах складываются в /usr/local, либо в /opt

А я вот ставлю пакетным менеджером vmware-player, и он падает в /opt. И flash-player тоже.

Не «не управляемые пакетным менеджером», а «не входящие в дистрибутив».

Это зависит. Админ локалхоста вполне может устроить помойку в /usr/local, если ему «так удобнее», как пишет наш виновник торжества. Он конечно ССЗБ, но с пакетами дистрибутива его художества конфликтовать не будут, по крайнней мере.

Админ локалхоста вполне может устроить помойку в /usr/local, если ему «так удобнее», как пишет наш виновник торжества. Он конечно ССЗБ

А куда ты предлагаешь сваливать самописные скрипты, например?

Нужно лишь потому, что линакс не умеет в объединения, в отличие от Plan 9.

Давно разучился?

А куда ты предлагаешь сваливать самописные скрипты, например?

Десяток скриптов в /usr/local/bin - это в принципе еще не помойка. Если они вручную туда админом положены, и он знает, что они такое и зачем нужны. Их конечно, по логике, хорошо бы тоже засунуть в пакет, но этот тот случай , когда проще не париться и сложить как есть.

А вот если нужно сделать wget && ./configure && make && make install на что-то стороннее и большое, то после пары-тройки таких «make && make install» в /usr/local закономерно возникает помойка.

А я вот ставлю пакетным менеджером vmware-player, и он падает в /opt. И flash-player тоже.

ну и что? Это не линукс.

Все правильно сделали. Короче PATH - больше счастья.

А куда ты предлагаешь сваливать самописные скрипты, например?

в ~/scripts/ очевидно же.

Никогда не умел. AUFS и прочие пристройки на проде юзать стрёмно

./automake.sh && ./configure тоже будешь в /usr/local запускать? :-D

Перегибаешь. В какой-нибудь корпоративной среде с многопользовательскими рабочими станциями разработкой никто заниматься не будет.

Насколько я помню, правильно писать именно /bin/sh и /usr/bin/env. Это не зависит от того, как файлы лежат в конкретной системе, это то, по каким путям эти бинарники ДОЛЖНЫ откликаться.

Перегибаешь.

Чувак, которому я отвечал четко написал: домашние каталоги девелоперов.

#!/bin/bash
в любой Unix-подобной системе

Ну да, конечно

> which bash
/usr/bin/bash
> which sh
/usr/bin/sh

Угадай систему по PATH. (Подсказка, это не арч :D)

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

Симлинки обеспечивают соответствие стандарту.

Физическое складывание всех бинарников в /usr обеспечивает возможность четко разделить систему на /usr, /var и /etc.

Никаких костылей тут нет.

А если у тебя, блин, «сервер» на «площадке»?

Без IPMI/IPKVM?

На самом деле давно надо было перетрясти структуру каталогов в Linux. При том основательно и продуманно. А то что сделали - это детский лепет. Всё что было разбросано по двум кучам, свалили в одну кучу.

Ну да, конечно

Ты не в куриваешь. sh ДОЛЖЕН откликаться по пути /bin/sh, иначе система не является FHS-compliant. А где он физически находится, пофиг.

Я в цитатку только /bin/bash включил )

Да я уже забыл как там пути указывать :)

Кэп спешит на помощь: «C:\Program Files»

Я в цитатку только /bin/bash включил )

which sh

Едрить, у кого-то из нас глюки.

А это что-бы проще было опознать поциента же ну

Чувак, которому я отвечал четко написал: домашние каталоги девелоперов.

Упс, пропустил. Твоя правда.

ОНО СЫРОЕ!

...

systemd всё ещё жутко сырой и разрабатывается по принципу «придумываем новые фичи во время их реализации», т.е. модель разработки как таковая отсутствует. А что касается багфиксов и стабилизации, то этого фактически нет — чего стоит только невозможность выключить компьютер из-за того, что неполучается отмонтировать /tmp. Много кто жаловался, да и у меня такое было.

Повторю: я ничего не имею против systemd, но он сырой и не готов для повсеместного использования. Когда-нибудь позже — да, возможно, но не сейчас.

Ну а с иерархией вообще никаких проблем нет: создан сим-линк, я вообще не заметил что что-то поменялось кроме как при `ls -l /`

Предыдущая иерархия была логична, а сваливать всё в одну директорию — это маразм. В федоре и то умнее сделали.

Пробуй калькулейт. Не пробуй сабайон.

Ага, цель — ничто, движение — всё.

Не «не управляемые пакетным менеджером», а «не входящие в дистрибутив».

Это зависит.

Что зависит? Об этих иерархиях сказано только то, что поставляемый и обновляемый в составе софт их не использует. А локальное использование вполне допускает как configure && make install, так и пакеты.

Леннарт и сам уже признавался, что принципиально пишет непортабельный Linux-only код

Леннарт признавался, что systemd активно использует linux-only фичи. Чувствуешь разницу?

переломный момент"

ломный

Тонко

Без IPMI/IPKVM?

Это такой вариант фразы «А у кого нет миллиарда, может идти нах*й» для тех, у кого нет миллиарда?

Леннарт и сам уже признавался, что принципиально пишет непортабельный Linux-only код

Леннарт признавался, что systemd активно использует linux-only фичи. Чувствуешь разницу?

Нет, объясни.

./automake.sh && ./configure тоже будешь в /usr/local запускать? :-D

ты из контекста в состоянии не вырывать, или такой толстый что аж жыр капает?

Чувак

В штанах у тебя чувак. Я тебе уже раньше два раза сказал - ИДИ РУССКИЙ УЧИ, потом с дяденьками визжи. «Чувак» мля )))

Не Леннарт пишет linux-only код, а бздуны все еще используют HAL и не умеют в cgroups. Очевидно же. Из-за хала их даже кедорасы кинули.

Кстати, тем, кто тут опять кричит про «единственный плюс - как обычно», напоминаю про https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

напоминаю про https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits 2) even if I'm wrong, these things are not hugely important

Против веры не попрешь.

ОНО СЫРОЕ

Идите-ка на дебиан, там будет и штабильность, и файрфокс 10, все дела.

но он сырой и не готов для повсеместного использования

Конкретные претензии будут? Системд отказывается стартовать сервис, для него нет нужного service-файла с описанием (хотя его написать-то - одна минута), он отказывается запускаться? Или «поцоны не ставьте там вирус у меня от этого дрянья брат умер»?

Предыдущая иерархия была логична

Тут уже говорилось, что никогда не была она логична. Потому что не может быть логична иерархия, созданная из-за нехватки места на 3-мегабайтном диске и не соблюдаемая никем. (Кстати, я вот мечтаю, что все конфиги наконец перестанут сваливать в виде скрытых файлов в ~ и перенесут наконец в XDG_CONFIG_DIRS. Или скрытые файлы - тоже логично?)

Это у кого еще вера: у того, кто написал 10 объективных плюсов, или у того, кто их не читал, зато придрался к фразе «'написан леннартом не на баше' - не объективный недостаток»?

Нет не логичнее. /usr обычно располагают на отдельном разделе поэтому в /bin и /sbin обычно кладутся те бинари без которых невозможно нормально загрузиться и восстановить систему. Получается что теперь если по каким либо причинам каталог /usr окажется не смонтированным вам останется только весла сушить. Если я все правильно понял, сам арчем не пользуюсь.

Лол, а если / останется несмонтированным?

Про initrd слышали когда-нибудь?

Плох тем, что теперь хрен тебе, а не компактная, неубиваемая r/o root fs.

https://en.wikipedia.org/wiki/Initrd