Как стать автором
Обновить

Комментарии 94

я бы наверно переименовал название статьи, все так и это не «организация файловой системы» это скорее организация установки приложений на файловой системе, ну наверно как то так…
так как тема «организация файловой системы» обычно понимают более глубинный смысл, ну там всякие монирования ФС и т.д.
Название: О некоторых аспектах
Название вообще очень понравилось — эдакое предельно-наукообразное =)
Ну, это типа полушутка. ;)
Это типа полуграмотность.
Потому что можно сказать «К вопросу об организации файловой системы», а можно сказать «О некоторых аспектах организации файловой системы». И то, и другое будет по-русски.
А «К вопросу о некоторых аспектах организации файловой системы» — это примерно как у советских классиков «наличие отсутствия пропитанных шпал».
С шутками вообще сложно все.
мне всегда было интересно (как не очень посвященному в вопросах разработки под *n?x человеку) как программисту в этих системах выбирать банальное имя своего исполняемого файла или библиотеки?
Лучше руководствовать posix (например здесь www.unix.org/single_unix_specification/) и здравым смыслом.
оно, конечно, хорошо и правильно — читать man-ы, rfc и прочее… но времени как обычно немного.
В двух словах можно ответ на мой вопрос?
Имя должно состоять только из латинницы цифр и. _ —. Если случилось так, что преписывается стандартная утилита, там особые требования. Все.
в общем-то как я и думал — именной ад. Я же как программист не могу знать имена всех утилит в мире nix, согласитесь?
Базовые — в Вашем дистрибутиве. Набираете буквы, жмете ТАБ, и или дописывает, или нет. Еще можно по базе данных пакетов Дебиана искать, там есть практически все. Я это в смысле проверки отсутствия конфликта имен.
Вы предлагаете у себя на системе установить все доступные в мире пакеты? Это не решение проблемы, это максимум ее отсрочка, согласитесь?
Нет конечно, но основные там уже есть. Тоесть делаете в два шага:
1. Проверка в своем дистрибутиве, в установленных пакетах. Прошли проверку, идете к шагу 2.
2. www.debian.org ищете по их базе пакетов/файлов. Прошли проверку, на 99% можете быть уверены, что имя годится.
1. дебианом мир nix\bsd\macos\прочих не оканчиватся
2. и вообще это не вариант, т.к. всегда есть временной лаг между внесением вашего пакета в пакеты дебиана, и миром.
Да, нет в мире совершенства (С) Лис из маленького принца.
Вам шашечки или ехать?
Полную гарантию, что данное имя не используется для лежащей у кого-то в ~/bin утилиты, вам не даст ни кто.
Если вы хотите максимально быстро придумать уникальное имя — придумайте любое и хешируйте его. Наверняка имя 5bb062356cddb5d2c0ef41eb2660cb06 не занято ни для одной утилиты.
Для всего остального достаточно проверки наличия этого файла в пакетах для вашего дистрибутива (наверняка везде есть аналоги apt-file), гугла и возможно проверки в дебиановских дистрах, как наиболее больших на данный момент.
угу, это «не баг, это фича». Ок. Закрыли бесполезную дискуссию.
кстати гугл выдал мне: Результаты 1 — 8 из 8 для 5bb062356cddb5d2c0ef41eb2660cb06. (0,09 секунд)

вот и думайте что вы придумали уникальность )
Поставьте в /opt/you_package/bin и радуйтесь
Их совсем немного, помотрите таки стандарт. Вообще, главное — это здравый смысл.
Ну не знаю. Если что-то действительно новое, то здесь есть проблемы. А если Вы что-то совершенствуете, то вполне резонно указать это в имени, например ftp-ng или ftp-ipv6-superbit.
/>
* admin
* alias
* ar
* asa
* at
* awk
* basename
* batch
* bc
* bg
* break
* c99
* cal
* cat
* cd
* cflow
* chgrp
* chmod
* chown
* cksum
* cmp
* colon
* comm
* command
* compress
* continue
* cp
* crontab
* csplit
* ctags
* cut
* cxref
* date
* dd
* delta
* df
* diff
* dirname
* dot
* du
* echo
* ed
* env
* eval
* ex
* exec
* exit
* expand
* export
* expr
* false
* fc
* fg
* file
* find
* fold
* fort77
* fuser
* gencat
* get
* getconf
* getopts
* grep
* hash
* head
* iconv
* id
* ipcrm
* ipcs
* jobs
* join
* kill
* lex
* link
* ln
* locale
* localedef
* logger
* logname
* lp
* ls
* m4
* mailx
* make
* man
* mesg
* mkdir
* mkfifo
* more
* mv
* newgrp
* nice
* nl
* nm
* nohup
* od
* paste
* patch
* pathchk
* pax
* pr
* printf
* prs
* ps
* pwd
* qalter
* qdel
* qhold
* qmove
* qmsg
* qrerun
* qrls
* qselect
* qsig
* qstat
* qsub
* read
* readonly
* renice
* return
* rm
* rmdel
* rmdir
* sact
* sccs
* sed
* set
* sh
* shift
* sleep
* sort
* split
* strings
* strip
* stty
* tabs
* tail
* talk
* tee
* test
* time
* times
* touch
* tput
* tr
* trap
* true
* tsort
* tty
* type
* ulimit
* umask
* unalias
* uname
* uncompress
* unexpand
* unget
* uniq
* unlink
* unset
* uucp
* uudecode
* uuencode
* uustat
* uux
* val
* vi
* wait
* wc
* what
* who
* write
* xargs
* yacc
* zcat
Долго думали перед нажатием кнопки «написать»? Видимо, нет. А стоило бы.
Кто же мог знать что хабракат не работает. Теперь и не удалишь.
Отвечу с точки зрения пользователя: имя программы должно быть коротким, если программа в пакете одна, или все программы должны иметь общий префикс, если их много (как, например, было с git-*). Желательно, чтобы имя программы было как-то связано с тем, что она делает. Если это сделать не получилось, имя должно быть запоминающимся, например, из-за оригинальности: не сразу понятно, что guile — это интерпретатор Scheme, а totem — мультимедийный проигрыватель, но со временем запоминается. А если бы назывались inter_sc и playmult, запоминалось бы намного сложнее.
а знаете как я бы назвал свой клиент ftp? а так бы и назвал — ftp… но вот незадача — в системе уже есть файл ftp (да, лежит в другой директории, но это же надуманный пример). А теперь представим что ftp (оригинальный) лежит в /usr/local/bin, куда мне положить свой ftp? А что делать другим программистам, называющих свои ftp-клиенты именем ftp?
Можно посмотреть, как поступают другие. Называют например lftp.
С другой стороны, оригинальный ftp лежит в:

$ which ftp
/usr/bin/ftp


Если Вы положите свой ftp в /usr/local/bin, то в большинстве дистрибутивов при вводе команды ftp вызовется Ваш клиент, т.к. обычно в переменной $PATH /usr/local/bin идет раньше, чем /usr/bin

А еще можно вызывать программы с полным именем.
Называйте хоть троллейбусом, лишь бы конфликта имён не было и с точки зрения пользователя запоминалось. А пользователь может сам через систему альтернатив выбирать, кому называться 'ftp' в его системе:
$ ls -l /usr/bin/ftp
lrwxrwxrwx 1 root root 21 Май  1 16:06 /usr/bin/ftp -> /etc/alternatives/ftp


Другим программистам можно ничего особого не делать, в дебиане их программу как-то переименуют. Так что лучше сразу называют без конфликта имён.
Библиотеку тоже переименовать вздумают, или имя конфига, или что-то еще? Переименование не вариант и внесет дополнительные сложности и путаницу.
Предложите свой вариант решения задачи: как N систем (программистов то есть) без обмена данными друг с другом могут каждая себе выбрать гарантированно уникальное число K_i. А пока почему-то ничего лучше UUID не придумали.
Лично для меня есть два вида решений: приемлемые и неприемлемые.
Для меня приемлемой является система организации имен установленного ПО в windows (компания\продукт\etc.). Она работает (хоть и не всегда, но это лучше чем «все в куче», т.к. в этом случае риск возрастает в разы).

Для меня приемлемая система именования файлов в .NET GAC. Она работает.

Неприемлемо что при назывании бинарников или конфигов мне приходится лезть в гугл\базы имен и т.п.
Смотрите статью раздел про директорию "/opt"
Нет, она не работает. Вы не тот usecase сравниваете. Был usecase по поводу запуска из командной строки. В Windows это обслуживается ключом
'HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths', где тоже «всё в куче».

А если вас интересует про запуск из GUI, то бинарник называйте как хотите, всё равно ползователю отображается название из .desktop-файла.

> Неприемлемо что при назывании бинарников или конфигов мне приходится лезть в гугл\базы имен и т.п.
Я вам описал задачу в математических терминах. Приведите её формальное решение.

А ваше решение ничем не лучше (и по сути то же самое). Вот я программист и пишу калькулятор. Как я его назову? calc! Положу, конечно, в %programfiles%\mycompany\calc\calc.exe и обязательно пропишу в реестре в app paths… упс, теперь стандартный калькулятор не запускается (или мой не запускается).
>и обязательно пропишу в реестре в app paths…
как только вам дадут права туда писать, тем более что это не практикуется в windows. Надуманный пример, реальность такова что такого не бывает почти (очень мало ситуаций когда это нужно, и этим реально можно пренебречь).

>Я вам описал задачу в математических терминах. Приведите её формальное решение.

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

> как только вам дадут права туда писать

Дадут сразу же с правами администратора, которые необходимы для установки файлов в %programfiles%. А также для регистрации всякого остального COM (я ведь обязательно хочу сделать ActiveX из своего калькулятора).
COM можно регить и для пользователя только, без админ прав.

В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.

И опять же: можно, это не значит что так делают. В nix можно писать и в /boot, но мало кто пишет, не так ли?
> В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.

Насколько я помню, это противоречит guidelines для разработчиков программ Windows (для Designed for Windows XP почти наверняка). И ни один администратор не будет так настраивать систему, это глупо (потому что это Welcome to Windows 95). И поэтому ни один нормальный инсталлятор не будет работать без прав администратора даже если они реально и не понадобятся (да ещё хотя бы потому, что ему msi базу надо записать куда-то).

Так что давайте не перекручивать факты.

А чем мой пример calc надуманее вашего ftp я так и не понял. Мы оба воспользовались стандартными средствами системы и получили конфликт имён.
А еще почти все инсталяторы (по крайней мере вменяемые) позволяют выбрать каталог установки, так что не перекручивайте факты что вам нужно именно в %programfiles% — туда вас никто не заставляет лезть. Кроме того не вижу ничего криминального в том, чтобы дать пользователю туда писать папки (без прав перезаписи чужих файлов), в подкаталоги-то никто прав не дает, учтите это. Если он и испортит, то только что-то свое.

В тоже время в nix мне рекомендуется ставиться по вполне определенным каталогам содержащим чужие программы.

> Мы оба воспользовались стандартными средствами системы и получили конфликт имён.

И часто вы видели программы, меняющие path в винде?

На мой взгляд мой пример более реален, нежели ваш. Вот и вся разница. За сим давайте перестанем 8) вы и я прекрасно понимаем друг друга)
> А еще почти все инсталяторы (по крайней мере вменяемые) позволяют выбрать каталог установки, так что не перекручивайте факты что вам нужно именно в %programfiles% — туда вас никто не заставляет лезть.

Инсталлятор Office 2007. Написан самим MS. Вменяемее просто и быть не может. Попробуйте поставьте офис к себе в Документы без прав администратора. Я не пробовал, но 100 к 1 что не получится.

Дело в том, что нужно перестать сравнивать апельсины с яблоками. Изначально был usecase про запуск из командной строки. А для его выполнения в Windows нужно или менять path или добавлять в app paths. Первое редкость, а не делать второго — дурной тон.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо! Однако мне кажется, что проблемы с зависимостями при использовании менеджера пакетов несколько преувеличены. За три года использования Linux, мне так и не удалось с ними встретиться.
Это сейчас научились работать и народу много работает над этим. А раньше было сплошь и рядом.
> Надеюсь статья будет полезной.
А чем она может быть полезной?
Обо всём и ни о чём.
Все-таки нелишне было бы упомянуть что все рассматривается для Debian/Ubuntu большими буквами, или перенести в Убунтарий. В других дистрибутивах могут быть свои полиси, к слову.
В статье есть оговорка, что примеры относятся к Debian/Ubunu. В основном же статья, ИМХО, применима к любому дистрибутиву.
man hier для широких масс?
О, кстати, добавлю в литературу.
тогда уж и pathname.com/fhs/ надо добавить.
Это там есть.
ТОка сервер уже лежит.
И текст сильно по мотивам, много чего полезного пропущено.
Кстати, что именно? Интересно мнение.
Пропущено про гибридные системы (x86/x86_64) в которых есть lib64 и lib, но может быть lib32 и lib. Каталоги второго уровня выбраны как-то странно есть /var/lock, но ничего не сказано про /var/run и так далее. Кроме того часто встречаются и /srv и /usr/X11R6.
В FreeBSD cимволическая ссылка /usr/X11R6 -> /usr/local.
А в Linux'е?
Счас гляну. Значится так, в Debian-оподобных:

— Раньше было прямо в /usr/X11R6
— Теперь раскидано по /usr а из /usr/X11R6 ссылки на директории в /usr
Где как, в слаке так. Да и во Free так только с с 7-ой версии стало.
а можно как-нибудь ставить пакеты из репозиториев не имея рут доступа, используя тот же синаптик себе в home?
ИМХО, если только распаковать пакет, раскидать по домашнему директорию файлы и подкрутить настройки. И не факт, что удасться. Может можно что-нибудь с chroot замутить, но сам я никогда таким не занимался, обещать ничего на могу.
Только если вести БД пакетного менеджера у себя же в home.
А для установки наверняка понадобится делать chroot.
А для этого надо быть рутом либо иметь привилегию CAP_SYS_CHROOT.

А чтобы неподготовленная программа заработала без chroot, надо будет чтобы она нашла свои библиотеки (можно добиться установив LD_LIBRARY_PATH), а так же и остальные свои части (тут уже от программы самой зависит).
В целом, проще и правильнее будет её пересобрать из исходников, задав правильный --prefix для configure.
Название имеет смысл изменить на что-нибудь вроде «Проблемы файловой организации системы UNIX/Linux», потому как файловые системы это более низкий уровень и к иерархической структуре файлов в системе он имеет отдаленное отношение.
Мельком проскорллил, мои мысли: новичкам наверняка пригодится, а тем кто хоть немного знаком с юникс-лайк системами не стоит тратить время, ничего нового не узнаете.
> Название имеет смысл изменить на что-нибудь вроде «Проблемы файловой организации системы UNIX/Linux», потому как файловые системы это более низкий уровень и к иерархической структуре файлов в системе он имеет отдаленное отношение.

Однако же Filesystem Hierarchy Standard примерно про то же самое. Есть просто некоторая двойственность в терминологии.
С какой стати Linux внезапно стал UNIX? Отродясь был GNU/Linux (GNU == GNU is Not Unix).
Это вопрос религии, я в религию не лезу.
Это не вопрос религии. Это вопрос правильного называния вещей своими именами и не приписывания им тех свойств, которыми эти вещи не обладают.

Линуксойды, как правило, любители, «гики». Не обременяющие себя академическими знаниями. UNIX писали учёные-программисты. Linux — студенты. :)
Да ладно! Неужели?
Ваша Бздя ничуть не больше Unix, чем Linux, если вы про то.
И пишут ее те же студенты, а никак не ученые.
Под UNIX/Linux я имел в виду не то, о чем вы подумали, а всего-лишь UNIX или Linux.
Спасибо. Помогли разобраться.
Недавно начал к Дебиану присматриваться и сразу же столкнулся с проблемой, куда ставить программы, которых нет в репах.
Хотелось бы ещё узнать о других директориях.
easylinux.ru/node/170
ващет, тут вроде все расписано (ссылка из топика)
Там все написано правильно, но я бы еще осветил причины, почему организовано именно так, а не иначе.
Я как раз думаю, писать ли статью о других директориях. Склоняюсь, что надо, хотя доступных материалов много, но мне самому нравится получать информацию в виде статей. Прочитал статью, получил основу. Надо разобраться лучше — смотришь другие материалы. Но общее направление уже понял.
Программы, собранные вручную и вне системы пакетного менеджмента, в Linux ставятся в каталог /opt или в домашний каталог пользователя.
Откуда информация?
ПО, устанавливаемое локально не должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП).

Если убрать двойное отрицание, то получается, что «ПО, устанавливаемое локально должно быть в опасности от переписывания при обновлении системы (имеется в виду обновление через МП).». То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь? Или я неправильно понял адски завёрнутую фразу?
> То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь?
может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает). вообще при любой установке любого компонента может что-то слететь.
Но обычно такого не бывает и обновления проходят более-менее гладко… вчера например обновился FF до версии 3.5, половина плагинов не работает 8-)
> может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает).

А в closed-source кто-то что-то гарантирует или отвечает? См. крики людей по поводу того, что после установки SP2 на XP система перестала работать и отнюдь не из-за пиратского софта. Да и вообще MS всю ответственность с себя за любые потери в EULA снимает.
Есть стратегия развертывания ZeroCopy, она применима и к nix, она дает указанные гарантии и многие продукты так и ставятся…

По поводу гарантий, все зависит от заказчика 8) Кроме того, я знаю к кому обратиться за исправлением (телефоны\конкретные люди), а не писать на форумах «боже, что-то случилось и я не могу работать, как все вернуть назад?», что дает мне некое душевное спокойствие.
Странно, тут-то как раз есть кому писать. Ответственности расписаны, email-ы есть. Вы о чем?
Вопрос приоритетности решений моих проблем в этих двух случаях.
Нет, ничего слететь не может, это я опечатался.
Пардон, моя ошибка, сейчас поправлю. Следует читать:

«ПО, устанавливаемое локально должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП)»

Смысл — гарантируется, что МП ничего не делает в иерархии /usr/local

Некоторая неуклюжесть из-за того, что это полиси — указания мэйнтенерам пакетов.

Linux это не UNIX

Отрицание UNIX в самой аббревиатуре-акрониме GNU (GNU is Not Unix) — обязательной приставке к слову Linux (GNU/Linux).
Это имитация UNIX. Более-менее удачная и только.

То, что вы написали о файловых системах, относится только к GNU/Linux, но никак не к UNIX.
Например, каталог /usr/local в FreeBSD является штатным каталогом установки приложений из «портов» оригинальных авторских исходников и бинарных пакетов.

Идеология FreeBSD, наследника BSD Unix, настолько отличается от Linux, что даже в системных программах (в Linux они называются coreutils) весьма много нюансов.
Успокойтесь, ваше BSD тоже ни разу не тру-юникс, потому что сертификата нету.
«Без бумажки ты — кака...» :)

В исходниках FreeBSD встречается копирайт AT&T. Наличие этих файлов было улажено мировой договорённостью между Novell и CSRG после судебного процесса в 1994 году. Около 70 файлов было оставлено с копирайтом USL. Часть из них переписана.

BSD защищала себя в суде c 1992 по 1994 годы от посягательств на свободный код, написанный в университетских стенах энтузиастами.

Ядро Linux писалось с нуля в 1991 году, оно начиналось как терминальная программа доступа к университетскому серверу под VMS с использованием инструментов разработки учебной системы Minix. Поддержка POSIX реализована в Linux позднее, чем в BSD-Unix. А нормальный доступ в Интернет и работа с протоколами прикладного уровня в Linux были отлажены только лишь в конце 90-х.
мне нравится freeBSD и не нравятся только религиозные фанатики, которые гордятся крутыми корнями, и показывают слабый результат в текущем времени.
Почему «показывают слабый результат»? Откуда такая уверенность в превосходстве Linux в текущем времени? Ядро 2.26.30 уже научилось нормально работать с ALSA? GNOME 2.26.3 с критическими исправлениями уже есть в репозиториях популярных дистрибутивов? Firefox 3.5 есть в репозиториях?
Как насчёт экспортирования RAW-разделов винчестеров по сети? Какой прогресс в портировании ZFS на Linux? Почему Btrfs 0.19 не поддерживает совместимость «сверху вниз», а только «снизу вверх»? Для Ext4 уже написали онлайновый дефрагментатор, а то люди жалуются на деградацию производительности со временем?
Добавил в статью, в раздел «Другие ОС» короткий раздельчик про FreeBSD.
Пакеты это примерно то же самое, что и пакеты в Debian/Ubuntu.Несовсем. Пакеты в Debian сильнее гранулированы. Пакеты в FreeBSD практически всегда соответствуют авторской единице инсталляции.

Например.
Sun JavaSE SDK в репозитории Ubuntu/Debian представлены несколькими пакетами: sun-java6-jdk, sun-java6-bin, sun-java6-demo, sun-java6-source. (Для поддержки русского языка нужно установить sun-java6-fonts, который вне обязательных зависимостей);
Sun JavaSE SDK в коллекции портов FreeBSD представлены только одним пакетом: jdk-1.6.0.3p4_11 (порт /usr/ports/java/jdk16), в котором всё это есть.

думаю, что если Вы не делаете своего порта, для поддержания порядка, можно использовать программу xstow.
Ага.
xstow 0.5.1_1
Enhanced replacement for GNU stow written in C++
There is no maintainer for this port.
Any concerns regarding this port should be directed to the FreeBSD Ports mailing list via ports@FreeBSD.org search for ports maintained by this maintainer
Port Added: 01 Jan 2003 16:01:06

XStow is a replacement of GNU Stow written in C++. It supports all features
of Stow with some extensions.

XStow as GNU Stow, are programs for managing the installation of software
packages, keeping them separate (/usr/local/stow/emacs
vs. /usr/local/stow/perl, for example) while making them appear to be
installed in the same place (/usr/local).

WWW: xstow.sourceforge.net/

— AlanE <alane@freebsd.org> 20021231

To install the port: cd /usr/ports/sysutils/xstow/ && make install clean
To add the package: pkg_add -r xstow
www.freshports.org/sysutils/xstow/
> Несовсем. Пакеты в Debian сильнее гранулированы. Пакеты в FreeBSD практически всегда соответствуют авторской единице инсталляции

Конечно, они не соответствуют один-в-один, я имею в виду, что они выполняют примерно те же функции, что и пакеты в Debian.
Хорошая заметка для начинающих. Почему нет?
Ну а чего тогда про MacOS не сказали? Там для пользовательских программ — первый вариант, для системных — второй
Не совсем понял про варианты, если чуть-чуть подробнее растолкуете, добавлю про Мак, просто БСД я когда-то трогал и возился чуть-чуть, а МАКа и близко не видел.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации