Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 149
Обычно /sbin и /usr/sbin присутствуют в переменной PATH только у рута
А он в него и не лазит, а посмотереть IP хочет, что бы попросить вендора выдать лицензию на софтинку которая с привязкой к IP. Более того `ip` лежит в /bin а `ifconfig` в /sbin. При этом `ip` более функционален. Автор статьи прав. Кроме того Solaris делает /bin /sbin симлинками внуть /usr много лет. Автор статьи прав на все 100%, разделение надуманно.
в Gentoo ip лежит в /sbin, а ifconfig /bin =)
Оба их в /sbin! :D
Конечно
$ which ifconfig
/sbin/ifconfig
$ which ip
/sbin/ip
$ cat /etc/gentoo-release
Gentoo Base System release 2.0.3
$ which ifconfig
/sbin/ifconfig
$ which ip
/sbin/ip
$ cat /etc/gentoo-release
Gentoo Base System release 2.0.3
Обновитесь. (~amd64)
sys-apps/iproute2-3.3.0
sys-apps/net-tools-1.60_p20120127084908
sys-apps/iproute2-3.3.0
sys-apps/net-tools-1.60_p20120127084908
Поставил iproute2-3.3.0, путь не изменился, x86 и amd64.
ifconfig из net-tools
ip зато из iproute2
Дык у нас-то ifconfig лежит в разных местах!
Заявлено было, что и ip, и ifconfig лежат в /bin.
iproute2 я обновил до означенной версии, ip остался лежать в /sbin.
net-tools обновлять до нестабильной версии не хочу, но мне и пофиг. Автор заявлял, что у него A и A, я показал, что первое A это Б. Доказывать второе А не вижу смысла.
iproute2 я обновил до означенной версии, ip остался лежать в /sbin.
net-tools обновлять до нестабильной версии не хочу, но мне и пофиг. Автор заявлял, что у него A и A, я показал, что первое A это Б. Доказывать второе А не вижу смысла.
> Пользователю не за чем лезть в ifconfig
До тех пор, пока он не захочет sudo ifconfig, на что он имеет право не но имеет в PATH ;)
До тех пор, пока он не захочет sudo ifconfig, на что он имеет право не но имеет в PATH ;)
Что-то тут не чисто:
user@gentoo ~ $ ifconfig
-bash: ifconfig: command not found
user@gentoo ~ $ sudo ifconfig
Password:
eth0 Link encap:Ethernet HWaddr 00:02:44:13:26:5a
inet addr:10.64.69.44 Bcast:10.64.71.255 Mask:255.255.248.0
inet6 addr: fe80::202:44ff:fe13:265a/64 Scope:Link
....
Потому что sudo запусает от имени суперпользователя (кэп) и, вероятно, использует его переменную $PATH. Нет возможности проверить, на моей серверной убунте:
someuser@pyxis-server:/$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
someuser@pyxis-server:/$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
ответ кроется в сравнении ввывода:
и
someuser@pyxis-server:/$ echo $PATHи
someuser@pyxis-server:/$ sudo echo $PATHЯ онечно дурак, но не совсем, проверил, прежде чем отписываться.
someuser@pyxis-server:~$ sudo echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
P.S. Вручную $PATH не правил.
someuser@pyxis-server:~$ sudo echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
P.S. Вручную $PATH не правил.
Такое сравнение некорректно, вывод будет идентичен: шелл подставляет переменные окружения ещё до запуска команды, реально выполняться будут echo /usr/local/bin:… и sudo echo /usr/local/bin:…
Для корректного сравнения вторая команда должна быть, например, sudo bash -c 'echo $PATH' с одинарными кавычками.
Для корректного сравнения вторая команда должна быть, например, sudo bash -c 'echo $PATH' с одинарными кавычками.
И ведь правда:
user@gentoo / $ echo $PATH
/bin:/usr/bin
user@gentoo / $ sudo sh -c 'echo $PATH'
Password:
/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin
Пользователь и в консоль не полезет никогда. А если уж полезет, чертыхнется и допишет /sbin перед ifconfig.
Разные пути — это не защита от юзера. Не пофиг ли ему, сколько команд будет после нажатия на tab — 5000 или 5500?
Разные пути — это не защита от юзера. Не пофиг ли ему, сколько команд будет после нажатия на tab — 5000 или 5500?
Радостно, что кто-то занимается такими вопросами, а то ведь пользователям Ubuntu, наверное, вообще без разницы, а там накручено так много, что мои эстетические чувства тошнит моментально.
А пользователей это и не должно волновать. Система должна работать, а как это будет реализовано дело десятое. Это проблемы вендоров дистрибутива и эстетствующих перфекционистов.
Может быть и не должно, но иногда волнует. Иногда пользователю нужно погрузиться в недра системы, поправить там что-нибудь. Чем более логично там все устроено (сейчас не конкретно про FHS), тем более вероятно что пользователь разберется, а не скажет «Непонятный этот ваш Linux».
То что пользователю не обязательно знать детали реализации системы не означает что система должна быть неоправданно сложной. Она должна быть настолько сложной насколько это необходимо для решения задачи.
«Логично» в данном случае очень условная величина. Кому логично? Разработчику системы/софта/специалисту в данной области или пользователю который только что узнал кучу новых непонятных слов?
Ставлю плитку шоколада Алёнка на то что среднестатистический пользователь пойдёт в гугл и будет искать что то вроде «как сделать %action% в %distrib%», найдёт howto (хороший или не очень) и будет вбивать команду за командой (make & make install — яркий представитель плохого совета. люди, собирайте пакеты =( ), не читая маны по используемым инструментам. И очень хорошо если после этого обновление до новой версии пройдёт без приключений. И не надо говорить что пользователь ССЗБ, если он использует левые howto.
Логичность/простота системы очень слабый мотиватор. Пользователь хочет решить проблему, а не изучать инструмент для решения проблемы.
Чем более логично там все устроено (сейчас не конкретно про FHS), тем более вероятно что пользователь разберется, а не скажет «Непонятный этот ваш Linux».
«Логично» в данном случае очень условная величина. Кому логично? Разработчику системы/софта/специалисту в данной области или пользователю который только что узнал кучу новых непонятных слов?
Ставлю плитку шоколада Алёнка на то что среднестатистический пользователь пойдёт в гугл и будет искать что то вроде «как сделать %action% в %distrib%», найдёт howto (хороший или не очень) и будет вбивать команду за командой (make & make install — яркий представитель плохого совета. люди, собирайте пакеты =( ), не читая маны по используемым инструментам. И очень хорошо если после этого обновление до новой версии пройдёт без приключений. И не надо говорить что пользователь ССЗБ, если он использует левые howto.
Логичность/простота системы очень слабый мотиватор. Пользователь хочет решить проблему, а не изучать инструмент для решения проблемы.
Если про разных людей, то айтишников отдельно, пользователей отдельно. И я тебя уверяю что если человеку не наплевать как работает компьютер пока он работает, то это либо айтишник, либо сочувствующий. Обычным пользователям плевать как реализована звуковая подсистема пока она исправно воспроизводит музыку. OSS, ALSA, etc ему ничего не скажет и душевной травмы от особенностей подсистемы он не испытает.
И это правильно.
Компьютер и OS должны подстраиваться под своего пользователя и обеспечивать ему комфортную, продуктивную работу. Тут не может быть двух мнений.
Кому надо сам соберёт OS своей мечты, благо Gentoo и LFS в помощь.
И это правильно.
Компьютер и OS должны подстраиваться под своего пользователя и обеспечивать ему комфортную, продуктивную работу. Тут не может быть двух мнений.
Кому надо сам соберёт OS своей мечты, благо Gentoo и LFS в помощь.
Мне кажется что не нужно создавать лишние препятствия на пути «пользователь -> IT-шник». Да и простых пользователей не надо отпугивать. Система должна быть понятной, красивой, прозрачной. Она должна строиться по принципу «Понял общую концепцию, во многом разберешься интуитивно», а не «Запомнить всё!».
Конечно это не распространяется на всё, например, написать драйвер все равно сложно, какой бы логичной не была система в целом. Но «домашне-малоофисно-административные» задачи должны выполняться легко. Точнее, не должно быть лишней, надуманной сложности.
Конечно это не распространяется на всё, например, написать драйвер все равно сложно, какой бы логичной не была система в целом. Но «домашне-малоофисно-административные» задачи должны выполняться легко. Точнее, не должно быть лишней, надуманной сложности.
Не понимаю смысл разделения /bin и /usr/bin. Оно реально не нужно, /use/local вполне понятно почему существует, /opt костыль для злобных буратино которые используют бинарные дистрибутивы. А sbin это просто то, что должно быть доступно только руту.
Вот только чаще всего там лежит собранный из сорцев nginx с пачкой модулей и ffmpeg со свежими либами.
Это у кого там nginx и т.п.?
У рубистов и тех кому нужны 3rd-party модули.
я имею ввиду в каком дистрибутиве?
В это в любом дистрибутиве. passanger например туда по-дефолту ставит в налюбой ОС nginx со своим модулем. Туда же все кому лень собирать свой пакет ставят его с 3rd-party модулями. Туда же некоторые мэинтейнеры ставят свои пакеты если они сильно отличаются от официальный (например официально пакет разбит на 10 частей, а тут один пакет все в одном). Вообщем ситуаций когда туда ставится, что-то много. и такие ситуации обычно возникают в дистрибутивах с бинарной дистрибьюцией.
./configure && make && make install — поставит пакет в /usr/local/
Как выше написал John_Minority, туда ставятся коммерческие продукты и и.п.
Например java.
Как выше написал John_Minority, туда ставятся коммерческие продукты и и.п.
Например java.
> Не понимаю смысл разделения /bin и /usr/bin. Оно реально не нужно.
Разделение на /bin и /usr/bin тебе очень пригодится, когда однажды вдруг окажется, что для установки нового софта уже не хватает места. Или если придется как-либо поменять разбиение диска на разделы, затрагивая /usr. Ты запросто загрузишь систему, не монтируя раздел /usr (и система будет работоспособна), расширишь этот раздел и продолжишь работу.
Не будь эти разделы отделены друг от друга, для работы с разделами пришлось бы грузиться с установочного диска или Live-CD.
Разделение на /bin и /usr/bin тебе очень пригодится, когда однажды вдруг окажется, что для установки нового софта уже не хватает места. Или если придется как-либо поменять разбиение диска на разделы, затрагивая /usr. Ты запросто загрузишь систему, не монтируя раздел /usr (и система будет работоспособна), расширишь этот раздел и продолжишь работу.
Не будь эти разделы отделены друг от друга, для работы с разделами пришлось бы грузиться с установочного диска или Live-CD.
Используйте LVM или еще лучше — ZFS.
ZFS по лицензионным соображениям никогда не будет в Linux в виде, ином, чем FUSE. Поэтому для систменых разделов он не годится.
линукспроблемы
zfsonlinux.org/
LVM решает почти все проблемы. Ext* ФС позволяют увеличение раздела «на лету» без отмонтирование, правда придется перевести его в ro.
LVM решает почти все проблемы. Ext* ФС позволяют увеличение раздела «на лету» без отмонтирование, правда придется перевести его в ro.
наглая, просто наглейшая ложь. zfsonlinux.org/
Эти проблемы уже давно решаются с помощью LVM. И вообще, что страшного в загрузке с LiveCD?
Ну и можно сделать жирный initrd с тулзами для работы с разделами и надуманность проблемы станет ещё очевиднее.
Ну и можно сделать жирный initrd с тулзами для работы с разделами и надуманность проблемы станет ещё очевиднее.
Вот как раз LVM я использую. Но LVM не отменит факта, что перед изменения объема раздела /usr его придется отмонтировать.
Насколько я знаю, нельзя остановить загрузку системы сразу после initrd, не монтируя «рабочие» разделы. Значит, и в этом случае для переразбиения /usr придется останавливать систему.
В загрузке LiceCD ничего особо страшного нет, кроме некоторых неудобств. LiveCD сначала надо отыскать (или скачать и прожечь), и работа с него гораздо медленнее.
Так что мне будет удобнее сделать «telinit S; umount /usr; увеличить /usr тем или иным способом; mount /usr; telinit 3», чем обслуживаться с помощью LiveCD. И если дистростроители всё-таки решат слить вместе /bin и /usr/bin, то лично мне станет грустно.
Насколько я знаю, нельзя остановить загрузку системы сразу после initrd, не монтируя «рабочие» разделы. Значит, и в этом случае для переразбиения /usr придется останавливать систему.
В загрузке LiceCD ничего особо страшного нет, кроме некоторых неудобств. LiveCD сначала надо отыскать (или скачать и прожечь), и работа с него гораздо медленнее.
Так что мне будет удобнее сделать «telinit S; umount /usr; увеличить /usr тем или иным способом; mount /usr; telinit 3», чем обслуживаться с помощью LiveCD. И если дистростроители всё-таки решат слить вместе /bin и /usr/bin, то лично мне станет грустно.
Можно делать второй, чуть более толстый, initrd/initramfs, содержащий необходимый минимум административных программ. выбор через GRUB/LILO.
Да, это небольшое дублирование файлов, но, думаю, потратить несколько десятков мегабайт не проблема при современных HDD/SSD.
Да, это небольшое дублирование файлов, но, думаю, потратить несколько десятков мегабайт не проблема при современных HDD/SSD.
> Но LVM не отменит факта, что перед изменения объема раздела /usr его придется отмонтировать.
Нет, не придется. Увеличение раздела в основых файловых системах идет на лету, без отмонтирываний.
Нет, не придется. Увеличение раздела в основых файловых системах идет на лету, без отмонтирываний.
Давайте более конкретно.
Основные файловые системы — это какие? Из наиболее распространенных далеко не все поддерживают изменение размеров без отмонтирования. XFS, например, поддерживает, а EXT3?
Основные файловые системы — это какие? Из наиболее распространенных далеко не все поддерживают изменение размеров без отмонтирования. XFS, например, поддерживает, а EXT3?
ext2/3/4, reiser3/4, xfs/jfs. Еще какие-то нужны? btrfs/zfs, by design из коробки обязаны, но лично не проверял.
По-моему, из перечисленных ФС менять размер на ходу умеют только xfs, btrfs, zfs. Ни одна из которых не предназначена для хранения корневого раздела.
Ну пойди и проверь. Я ресайзю xfs, ext3/4 и reiserfs по несколько раз в неделю иногда. А тут внезапно узнаю, что по чьему-то — нельзя. Огащаз.
Прочитал man. Ты прав (отчасти). У ext3 и reiserfs на ходу менять размер можно, но только в сторону увеличения и только если ядро поддерживает online resize (как правило, для ядер версий 2.6 и новее это так).
Ну так про ресайз вверх и был разговор. Вниз — у всех файлух плохо. Кто-то умеет только offline (extX), кто-то при mount -o ro (reiserfs), кто-то вообще не умеет (xfs).
Чтобы увеличить один раздел нужно же уменьшить другой, не?
1. Тот диск, с которого будешь брать свободное место, обычно может быть безболезненно отмонтирован
2. Если нет, можно создать loop-диск из файла, который положить диск со свободным местом и уже этот loop подключить как дополнительный раздел к исходному (если все-таки он изначально был на lvm, иначе никак).
3. Можно добавить дисков в систему
4. Можно увеличить исходные диски (были терабайтные — поставили двухтерабайтные — те же разделы остались, а свободного, неразмеченного места прибавилось).
5. Может быть тупо запасное место в volumegroup.
2. Если нет, можно создать loop-диск из файла, который положить диск со свободным местом и уже этот loop подключить как дополнительный раздел к исходному (если все-таки он изначально был на lvm, иначе никак).
3. Можно добавить дисков в систему
4. Можно увеличить исходные диски (были терабайтные — поставили двухтерабайтные — те же разделы остались, а свободного, неразмеченного места прибавилось).
5. Может быть тупо запасное место в volumegroup.
AFAIK, /usr частенько монтировался по сети, это некогда был основной, а то и единственный вариант во многих *nix-системах, собственно, отсюда и разделение. /bin (binaries), /sbin (system binaries) должны содержать программы, необходимые для минимальной загрузки и монтирования основных и пользовательских директорий, все пользовательские программы не являются системным минимумом и содержащие их разделы могут быть примонтированы по сети, в том числе после полной загрузки, в том числе и вручную. Это сейчас стандарт FHS (версии 2.3 вроде) не предусматривает обязательного монтирования по сети, и теоретически такое разделение в следующих версиях стандарта могут упразднить.
Дело тут не в разделах, можно вообще любую директорию в отдельный раздел выделить, если вы помните устройство иерархии файловых систем, и не обязательно это будет локальный носитель. Это вопрос логически правильного разделения системных и пользовательских файлов изначально.
Дело тут не в разделах, можно вообще любую директорию в отдельный раздел выделить, если вы помните устройство иерархии файловых систем, и не обязательно это будет локальный носитель. Это вопрос логически правильного разделения системных и пользовательских файлов изначально.
Ну, мы вот разрабатываем некий софт. Это, конечно, не встраиваемая система, но софт запускается на бездисковых рабочих станциях с загрузкой по сети. Из-за кривущего TFTP, который качает файлы с черепашьей скоростью, родилось вынужденное решение: корневой образ в squashfs грузится через tftp (сейчас примерно 5 Мб), а /usr монтируется к нему уже в процессе выполнения init.
О_О по tftp качается initrd, потом по nfs.
Так оно и есть. Но это всё равно костыли и подпорки, у нас тот образ не такой большой, чтобы был смысл его по NFS монтировать, а не сразу в память разворачивать.
Просто по tftp init весом в 60 мегабайт качается примерно минуту вместо логичных 6 секунд :(
Просто по tftp init весом в 60 мегабайт качается примерно минуту вместо логичных 6 секунд :(
Но там по крайней мере понятно всегда, где искать настройки софта. А вот угадайте, в какой папке хранятся конфиги постгреса на федоре?
Неправильно понимаете назначение sbin. sbin — статическая сборка. Да, там критически важные для работы системы бинарники. И их собирают статически. А те бинарники, что не статические — в bin.
Может быть разве что когда-то были:
$ ls /sbin/* | wc -l
154
$ ldd /sbin/* | grep 'not a dynamic executable' | wc -l
10
так было. но к сожалению сейчас уже нет — слишком много людей не подозревают о man 7 hier применительно к их системе и лепят отсебятину.
ru.wikipedia.org/wiki/FHS Все четко описано что и зачем.
Ну вообще я согласен с автором, скорее всего изначально деление было из-за ограничений в размере. А потом, все временное становится постоянным.
Fedora 17 будет делать линки в /usr fedoraproject.org/wiki/Features/UsrMove, высоки шансы что это же перейдет в RHEL.
Интересно, что события всего 40-летней давности, но для ежедневно использующих *nix-системы воспринимаются подобно тому, как верующие воспринимают события священного писания.
Кто-нибудь напишите автору, чтобы он написал об этом в Linux Foundation.
Да что им туда писать. Там же одни идиоты и дауны сидят. Не знают что и почему, так же как и зачем. Ничего не понимают, исторических подоплёк не помнят, ни знаний ни опыта у них нет. В общем компания «бюрократов» с улицы.
Зато ТС — вот он могуч. Он аж студент МГУ, знает всё на свете. Он читал этот их FHS и понял, что это полная чушь. Его опыт будет покруче, чем опыт всех, кто пишет FHS.
И поэтому он будет писать свои предложения не в список рассылки FHS beta 3.0 (https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss), а на Хабр, где полно таких же хомячков, которые его тут же поддержат.
Зато ТС — вот он могуч. Он аж студент МГУ, знает всё на свете. Он читал этот их FHS и понял, что это полная чушь. Его опыт будет покруче, чем опыт всех, кто пишет FHS.
И поэтому он будет писать свои предложения не в список рассылки FHS beta 3.0 (https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss), а на Хабр, где полно таких же хомячков, которые его тут же поддержат.
На всякий случай напомню, что это перевод. Я и настоящий автор письма — разные люди.
перед заголовком топика.
Разделение вполне грамотное. Главное, чтобы всякие поцтеринги не совали свой нос и не переносили основные бинарники из coreutils в /usr/bin или (еще хуже) /usr/local/bin.
Вот, кстати, по-моему, директория /usr/local не нужна. Так же, как и /opt.
Вот, кстати, по-моему, директория /usr/local не нужна. Так же, как и /opt.
/usr/local и /opt нужны, чтобы система не превращалась в файлопомойку. Этакие резервации для файлов, не контролируемых пакетным менеджером.
Кстати, насчет ненужных директорий. Даже в арче есть всякая гадость, которая гадит где попало:
chrome, CUDA SDK и qt3 (?) почему-то мусорят в неподходящие директории.
Еще в арче есть любители поднамусорить в ненужную директорию /usr/local:
mathGL установился в /usr/local, а не /usr. Но это я сам виноват: в репозитории староватая версия была, а новую я собрал наспех — вот и получил мусор там, где его быть не должно.
ls /opt/
cuda-toolkit/ google/ qt/
chrome, CUDA SDK и qt3 (?) почему-то мусорят в неподходящие директории.
Еще в арче есть любители поднамусорить в ненужную директорию /usr/local:
ls /usr/local/bin/
mglconv* mgl_example* mgl_glut_example*
ls /usr/local/lib/
libmgl.a libmgl-glut.a libmgl-glut.so@ libmgl-glut.so.6.0.0* libmgl.so@ libmgl.so.6.0.0* libmgl-wnd.a libmgl-wnd.so@ libmgl-wnd.so.6.0.0*
mathGL установился в /usr/local, а не /usr. Но это я сам виноват: в репозитории староватая версия была, а новую я собрал наспех — вот и получил мусор там, где его быть не должно.
Не удивлюсь, если появится ещё и /opt/local…
Значит, вы были к этому готовы, сказал MacPorts… =)
Спасибо, очень познавательно! Стало намного понятнее эта каша из директорий.
Леннарт, перелогиньтесь.
Товарищи! Посмотрите на Plan9, его сделала партия Отцы Unix, там иерархия FS совсем другая. При этом Отцы считают его более Unix-way'ным чем сам Unix., еретики!
Так что, если что-то из-за исторических причин стало стандартом (FHS), это еще не значит что так должно быть всегда. Надо проще относиться к изменениям.
Так что, если что-то из-за исторических причин стало стандартом (FHS), это еще не значит что так должно быть всегда. Надо проще относиться к изменениям.
Имею /bin и /usr/bin отдельно по единственной причине: /bin это часть iniramfs и он доступен до монтирования /usr, где лежат все жирные программы. Таким образом, я имею минимальную систему размером 2 мегабайта, способную скачать с сети и прошить остальную систему.
Автор, динамически слинкованного баша тебе.
Это опенсорс. Не нравится? Сделай по-своему, а не пиши глупые высеры.
Не стоит забывать, что unix — очень универсальная система. Она может работать не только на домашнем компьютере с гигабайтами оперативки и терабайтными дисками, но и на устройстве с очень ограниченными ресурсами, вроде маршрутизатора.
Тот факт, что решение сделать иерархию /usr было принято больше 30 лет назад из-за нового диска, вовсе не значит, что оно устарело. Если его отменить, unix потеряет заметную часть своей гибкости.
А кто такой David Collier, которого автор цитирует в начале?
Тот факт, что решение сделать иерархию /usr было принято больше 30 лет назад из-за нового диска, вовсе не значит, что оно устарело. Если его отменить, unix потеряет заметную часть своей гибкости.
А кто такой David Collier, которого автор цитирует в начале?
«Я обеими рогами за! (с)» Наибольшей «тупорылостью» с точки зрения «насрать во все 100500 папок *bin» отличаются *bsd системы, IMHO это ужас.
При загрузке используется initrd или initramfs
Внимание, вопрос: для чего нужен этот костыль при самосборном ядре? Мне проще вкомпилировать нужные фичи (такие как драйверы для дискового контроллера и файловой системы на /), чем ковыряться с каким-то initrd, который по большому счету нигде кроме livecd не нужен.
Я так понимаю, нам еще автоматом предлагают отказаться от отдельного boot, потому что при современных тенденциях тянуть всякое г-но как можно ближе к ядру, размер initrd-образов через пару лет перевалит за те самые упоминаемые 100Mb.
А вот я в восторге от того, что есть стандарт на файловую систему и достаточно прозрачно и логично расписано, какие и где файлы должны находится.
Все эти призывы к упрощению и отказу от системы, «разработчик лучше знает» обычно кончаются неописуемым бардаком в расположении директориев и файлов. Типа, как на Андроиде. Есть остатки порядка, от Линукса и есть бардак, там где отступили от стандарта.
Я предпочитаю порядок.
Все эти призывы к упрощению и отказу от системы, «разработчик лучше знает» обычно кончаются неописуемым бардаком в расположении директориев и файлов. Типа, как на Андроиде. Есть остатки порядка, от Линукса и есть бардак, там где отступили от стандарта.
Я предпочитаю порядок.
Видимо недостаточно раз возникают с этим проблемы и такие посты.
А где на Андроиде бардак?
вы пробовали посмотреть в home пользователя на android?
в linux такое было где-то в начале 00х. потом одумались и сделали
.config .local и прочие «консолидирующие» каталоги.
ну и то что все называют свои каталоги кто как хочет — нет единого стиля и непонятно что есть конфиг программы и что есть данные программы.
а ещё часть народа хранит настройки на sdcard если её видят. а часть на external_sd. в итоге если sdcard это внутренняя память телефона, то всё там и хранится.
в общем бардачина полнейшая
в linux такое было где-то в начале 00х. потом одумались и сделали
.config .local и прочие «консолидирующие» каталоги.
ну и то что все называют свои каталоги кто как хочет — нет единого стиля и непонятно что есть конфиг программы и что есть данные программы.
а ещё часть народа хранит настройки на sdcard если её видят. а часть на external_sd. в итоге если sdcard это внутренняя память телефона, то всё там и хранится.
в общем бардачина полнейшая
Надо было бы ещё и lists.busybox.net/pipermail/busybox/2010-December/074202.html перевести — для полноты картины. ;-P
Стоп.
Флуд о /bin и /usr/bin — это пожалуйста. А вот sbin, просьба не трогать.
sbin — statically linked binary. Файлы, которые могут работать при любых обстоятельствах с файловой системой и недоступностью /lib.
Флуд о /bin и /usr/bin — это пожалуйста. А вот sbin, просьба не трогать.
sbin — statically linked binary. Файлы, которые могут работать при любых обстоятельствах с файловой системой и недоступностью /lib.
А еще есть (был) GoboLinux. Вполне себе красивая концепция: www.gobolinux.org/index.php?lang=ru_RU&page=k5
В Mac OS X есть потуги разобраться с этим бардаком. Но у них и нет задачи запускать систему в embedded
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разница между bin, sbin, usr/bin, usr/sbin