Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 94
я бы наверно переименовал название статьи, все так и это не «организация файловой системы» это скорее организация установки приложений на файловой системе, ну наверно как то так…
так как тема «организация файловой системы» обычно понимают более глубинный смысл, ну там всякие монирования ФС и т.д.
так как тема «организация файловой системы» обычно понимают более глубинный смысл, ну там всякие монирования ФС и т.д.
Название: О некоторых аспектах
Название вообще очень понравилось — эдакое предельно-наукообразное =)
Ну, это типа полушутка. ;)
Это типа полуграмотность.
Потому что можно сказать «К вопросу об организации файловой системы», а можно сказать «О некоторых аспектах организации файловой системы». И то, и другое будет по-русски.
А «К вопросу о некоторых аспектах организации файловой системы» — это примерно как у советских классиков «наличие отсутствия пропитанных шпал».
Потому что можно сказать «К вопросу об организации файловой системы», а можно сказать «О некоторых аспектах организации файловой системы». И то, и другое будет по-русски.
А «К вопросу о некоторых аспектах организации файловой системы» — это примерно как у советских классиков «наличие отсутствия пропитанных шпал».
мне всегда было интересно (как не очень посвященному в вопросах разработки под *n?x человеку) как программисту в этих системах выбирать банальное имя своего исполняемого файла или библиотеки?
Лучше руководствовать posix (например здесь www.unix.org/single_unix_specification/) и здравым смыслом.
оно, конечно, хорошо и правильно — читать man-ы, rfc и прочее… но времени как обычно немного.
В двух словах можно ответ на мой вопрос?
В двух словах можно ответ на мой вопрос?
Имя должно состоять только из латинницы цифр и. _ —. Если случилось так, что преписывается стандартная утилита, там особые требования. Все.
в общем-то как я и думал — именной ад. Я же как программист не могу знать имена всех утилит в мире nix, согласитесь?
Базовые — в Вашем дистрибутиве. Набираете буквы, жмете ТАБ, и или дописывает, или нет. Еще можно по базе данных пакетов Дебиана искать, там есть практически все. Я это в смысле проверки отсутствия конфликта имен.
Вы предлагаете у себя на системе установить все доступные в мире пакеты? Это не решение проблемы, это максимум ее отсрочка, согласитесь?
Нет конечно, но основные там уже есть. Тоесть делаете в два шага:
1. Проверка в своем дистрибутиве, в установленных пакетах. Прошли проверку, идете к шагу 2.
2. www.debian.org ищете по их базе пакетов/файлов. Прошли проверку, на 99% можете быть уверены, что имя годится.
1. Проверка в своем дистрибутиве, в установленных пакетах. Прошли проверку, идете к шагу 2.
2. www.debian.org ищете по их базе пакетов/файлов. Прошли проверку, на 99% можете быть уверены, что имя годится.
1. дебианом мир nix\bsd\macos\прочих не оканчиватся
2. и вообще это не вариант, т.к. всегда есть временной лаг между внесением вашего пакета в пакеты дебиана, и миром.
2. и вообще это не вариант, т.к. всегда есть временной лаг между внесением вашего пакета в пакеты дебиана, и миром.
Да, нет в мире совершенства (С) Лис из маленького принца.
Вам шашечки или ехать?
Полную гарантию, что данное имя не используется для лежащей у кого-то в ~/bin утилиты, вам не даст ни кто.
Если вы хотите максимально быстро придумать уникальное имя — придумайте любое и хешируйте его. Наверняка имя 5bb062356cddb5d2c0ef41eb2660cb06 не занято ни для одной утилиты.
Для всего остального достаточно проверки наличия этого файла в пакетах для вашего дистрибутива (наверняка везде есть аналоги apt-file), гугла и возможно проверки в дебиановских дистрах, как наиболее больших на данный момент.
Полную гарантию, что данное имя не используется для лежащей у кого-то в ~/bin утилиты, вам не даст ни кто.
Если вы хотите максимально быстро придумать уникальное имя — придумайте любое и хешируйте его. Наверняка имя 5bb062356cddb5d2c0ef41eb2660cb06 не занято ни для одной утилиты.
Для всего остального достаточно проверки наличия этого файла в пакетах для вашего дистрибутива (наверняка везде есть аналоги apt-file), гугла и возможно проверки в дебиановских дистрах, как наиболее больших на данный момент.
Поставьте в /opt/you_package/bin и радуйтесь
Их совсем немного, помотрите таки стандарт. Вообще, главное — это здравый смысл.
habrahabr.ru/blogs/linux/63414/#comment_1760118
это здравый смысл в именовании своих программ, но он дает проблемы, увы.
это здравый смысл в именовании своих программ, но он дает проблемы, увы.
/>
* 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
* 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 лежит в:
Если Вы положите свой ftp в /usr/local/bin, то в большинстве дистрибутивов при вводе команды ftp вызовется Ваш клиент, т.к. обычно в переменной $PATH /usr/local/bin идет раньше, чем /usr/bin
А еще можно вызывать программы с полным именем.
С другой стороны, оригинальный 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. Она работает.
Неприемлемо что при назывании бинарников или конфигов мне приходится лезть в гугл\базы имен и т.п.
Для меня приемлемой является система организации имен установленного ПО в 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… упс, теперь стандартный калькулятор не запускается (или мой не запускается).
'HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths', где тоже «всё в куче».
А если вас интересует про запуск из GUI, то бинарник называйте как хотите, всё равно ползователю отображается название из .desktop-файла.
> Неприемлемо что при назывании бинарников или конфигов мне приходится лезть в гугл\базы имен и т.п.
Я вам описал задачу в математических терминах. Приведите её формальное решение.
А ваше решение ничем не лучше (и по сути то же самое). Вот я программист и пишу калькулятор. Как я его назову? calc! Положу, конечно, в %programfiles%\mycompany\calc\calc.exe и обязательно пропишу в реестре в app paths… упс, теперь стандартный калькулятор не запускается (или мой не запускается).
>и обязательно пропишу в реестре в app paths…
как только вам дадут права туда писать, тем более что это не практикуется в windows. Надуманный пример, реальность такова что такого не бывает почти (очень мало ситуаций когда это нужно, и этим реально можно пренебречь).
>Я вам описал задачу в математических терминах. Приведите её формальное решение.
не становитесь занудой, я прекрасно понимаю что решение сложно и врядли осуществимо в реальности. Потому я и говорю лишь о преемственности решения для себя, а не о решении. Если можно уменьшить вероятность возникновения конфликтов — почему это не сделать?
как только вам дадут права туда писать, тем более что это не практикуется в windows. Надуманный пример, реальность такова что такого не бывает почти (очень мало ситуаций когда это нужно, и этим реально можно пренебречь).
>Я вам описал задачу в математических терминах. Приведите её формальное решение.
не становитесь занудой, я прекрасно понимаю что решение сложно и врядли осуществимо в реальности. Потому я и говорю лишь о преемственности решения для себя, а не о решении. Если можно уменьшить вероятность возникновения конфликтов — почему это не сделать?
> как только вам дадут права туда писать
Дадут сразу же с правами администратора, которые необходимы для установки файлов в %programfiles%. А также для регистрации всякого остального COM (я ведь обязательно хочу сделать ActiveX из своего калькулятора).
Дадут сразу же с правами администратора, которые необходимы для установки файлов в %programfiles%. А также для регистрации всякого остального COM (я ведь обязательно хочу сделать ActiveX из своего калькулятора).
COM можно регить и для пользователя только, без админ прав.
В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.
И опять же: можно, это не значит что так делают. В nix можно писать и в /boot, но мало кто пишет, не так ли?
В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.
И опять же: можно, это не значит что так делают. В nix можно писать и в /boot, но мало кто пишет, не так ли?
> В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.
Насколько я помню, это противоречит guidelines для разработчиков программ Windows (для Designed for Windows XP почти наверняка). И ни один администратор не будет так настраивать систему, это глупо (потому что это Welcome to Windows 95). И поэтому ни один нормальный инсталлятор не будет работать без прав администратора даже если они реально и не понадобятся (да ещё хотя бы потому, что ему msi базу надо записать куда-то).
Так что давайте не перекручивать факты.
А чем мой пример calc надуманее вашего ftp я так и не понял. Мы оба воспользовались стандартными средствами системы и получили конфликт имён.
Насколько я помню, это противоречит guidelines для разработчиков программ Windows (для Designed for Windows XP почти наверняка). И ни один администратор не будет так настраивать систему, это глупо (потому что это Welcome to Windows 95). И поэтому ни один нормальный инсталлятор не будет работать без прав администратора даже если они реально и не понадобятся (да ещё хотя бы потому, что ему msi базу надо записать куда-то).
Так что давайте не перекручивать факты.
А чем мой пример calc надуманее вашего ftp я так и не понял. Мы оба воспользовались стандартными средствами системы и получили конфликт имён.
А еще почти все инсталяторы (по крайней мере вменяемые) позволяют выбрать каталог установки, так что не перекручивайте факты что вам нужно именно в %programfiles% — туда вас никто не заставляет лезть. Кроме того не вижу ничего криминального в том, чтобы дать пользователю туда писать папки (без прав перезаписи чужих файлов), в подкаталоги-то никто прав не дает, учтите это. Если он и испортит, то только что-то свое.
В тоже время в nix мне рекомендуется ставиться по вполне определенным каталогам содержащим чужие программы.
> Мы оба воспользовались стандартными средствами системы и получили конфликт имён.
И часто вы видели программы, меняющие path в винде?
На мой взгляд мой пример более реален, нежели ваш. Вот и вся разница. За сим давайте перестанем 8) вы и я прекрасно понимаем друг друга)
В тоже время в nix мне рекомендуется ставиться по вполне определенным каталогам содержащим чужие программы.
> Мы оба воспользовались стандартными средствами системы и получили конфликт имён.
И часто вы видели программы, меняющие path в винде?
На мой взгляд мой пример более реален, нежели ваш. Вот и вся разница. За сим давайте перестанем 8) вы и я прекрасно понимаем друг друга)
> А еще почти все инсталяторы (по крайней мере вменяемые) позволяют выбрать каталог установки, так что не перекручивайте факты что вам нужно именно в %programfiles% — туда вас никто не заставляет лезть.
Инсталлятор Office 2007. Написан самим MS. Вменяемее просто и быть не может. Попробуйте поставьте офис к себе в Документы без прав администратора. Я не пробовал, но 100 к 1 что не получится.
Дело в том, что нужно перестать сравнивать апельсины с яблоками. Изначально был usecase про запуск из командной строки. А для его выполнения в Windows нужно или менять path или добавлять в app paths. Первое редкость, а не делать второго — дурной тон.
Инсталлятор Office 2007. Написан самим MS. Вменяемее просто и быть не может. Попробуйте поставьте офис к себе в Документы без прав администратора. Я не пробовал, но 100 к 1 что не получится.
Дело в том, что нужно перестать сравнивать апельсины с яблоками. Изначально был usecase про запуск из командной строки. А для его выполнения в Windows нужно или менять path или добавлять в app paths. Первое редкость, а не делать второго — дурной тон.
Спасибо! Однако мне кажется, что проблемы с зависимостями при использовании менеджера пакетов несколько преувеличены. За три года использования Linux, мне так и не удалось с ними встретиться.
> Надеюсь статья будет полезной.
А чем она может быть полезной?
Обо всём и ни о чём.
А чем она может быть полезной?
Обо всём и ни о чём.
Все-таки нелишне было бы упомянуть что все рассматривается для Debian/Ubuntu большими буквами, или перенести в Убунтарий. В других дистрибутивах могут быть свои полиси, к слову.
man hier для широких масс?
О, кстати, добавлю в литературу.
тогда уж и pathname.com/fhs/ надо добавить.
Это там есть.
ТОка сервер уже лежит.
И текст сильно по мотивам, много чего полезного пропущено.
а можно как-нибудь ставить пакеты из репозиториев не имея рут доступа, используя тот же синаптик себе в home?
ИМХО, если только распаковать пакет, раскидать по домашнему директорию файлы и подкрутить настройки. И не факт, что удасться. Может можно что-нибудь с chroot замутить, но сам я никогда таким не занимался, обещать ничего на могу.
Только если вести БД пакетного менеджера у себя же в home.
А для установки наверняка понадобится делать chroot.
А для этого надо быть рутом либо иметь привилегию CAP_SYS_CHROOT.
А чтобы неподготовленная программа заработала без chroot, надо будет чтобы она нашла свои библиотеки (можно добиться установив LD_LIBRARY_PATH), а так же и остальные свои части (тут уже от программы самой зависит).
В целом, проще и правильнее будет её пересобрать из исходников, задав правильный --prefix для configure.
А для установки наверняка понадобится делать chroot.
А для этого надо быть рутом либо иметь привилегию CAP_SYS_CHROOT.
А чтобы неподготовленная программа заработала без chroot, надо будет чтобы она нашла свои библиотеки (можно добиться установив LD_LIBRARY_PATH), а так же и остальные свои части (тут уже от программы самой зависит).
В целом, проще и правильнее будет её пересобрать из исходников, задав правильный --prefix для configure.
Название имеет смысл изменить на что-нибудь вроде «Проблемы файловой организации системы UNIX/Linux», потому как файловые системы это более низкий уровень и к иерархической структуре файлов в системе он имеет отдаленное отношение.
Мельком проскорллил, мои мысли: новичкам наверняка пригодится, а тем кто хоть немного знаком с юникс-лайк системами не стоит тратить время, ничего нового не узнаете.
Мельком проскорллил, мои мысли: новичкам наверняка пригодится, а тем кто хоть немного знаком с юникс-лайк системами не стоит тратить время, ничего нового не узнаете.
> Название имеет смысл изменить на что-нибудь вроде «Проблемы файловой организации системы UNIX/Linux», потому как файловые системы это более низкий уровень и к иерархической структуре файлов в системе он имеет отдаленное отношение.
Однако же Filesystem Hierarchy Standard примерно про то же самое. Есть просто некоторая двойственность в терминологии.
Однако же Filesystem Hierarchy Standard примерно про то же самое. Есть просто некоторая двойственность в терминологии.
С какой стати Linux внезапно стал UNIX? Отродясь был GNU/Linux (GNU == GNU is Not Unix).
Это вопрос религии, я в религию не лезу.
Под UNIX/Linux я имел в виду не то, о чем вы подумали, а всего-лишь UNIX или Linux.
Спасибо. Помогли разобраться.
Недавно начал к Дебиану присматриваться и сразу же столкнулся с проблемой, куда ставить программы, которых нет в репах.
Хотелось бы ещё узнать о других директориях.
Недавно начал к Дебиану присматриваться и сразу же столкнулся с проблемой, куда ставить программы, которых нет в репах.
Хотелось бы ещё узнать о других директориях.
easylinux.ru/node/170
ващет, тут вроде все расписано (ссылка из топика)
ващет, тут вроде все расписано (ссылка из топика)
Я как раз думаю, писать ли статью о других директориях. Склоняюсь, что надо, хотя доступных материалов много, но мне самому нравится получать информацию в виде статей. Прочитал статью, получил основу. Надо разобраться лучше — смотришь другие материалы. Но общее направление уже понял.
Программы, собранные вручную и вне системы пакетного менеджмента, в Linux ставятся в каталог /opt или в домашний каталог пользователя.
ПО, устанавливаемое локально не должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП).
Если убрать двойное отрицание, то получается, что «ПО, устанавливаемое локально должно быть в опасности от переписывания при обновлении системы (имеется в виду обновление через МП).». То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь? Или я неправильно понял адски завёрнутую фразу?
Если убрать двойное отрицание, то получается, что «ПО, устанавливаемое локально должно быть в опасности от переписывания при обновлении системы (имеется в виду обновление через МП).». То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь? Или я неправильно понял адски завёрнутую фразу?
> То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь?
может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает). вообще при любой установке любого компонента может что-то слететь.
Но обычно такого не бывает и обновления проходят более-менее гладко… вчера например обновился FF до версии 3.5, половина плагинов не работает 8-)
может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает). вообще при любой установке любого компонента может что-то слететь.
Но обычно такого не бывает и обновления проходят более-менее гладко… вчера например обновился FF до версии 3.5, половина плагинов не работает 8-)
> может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает).
А в closed-source кто-то что-то гарантирует или отвечает? См. крики людей по поводу того, что после установки SP2 на XP система перестала работать и отнюдь не из-за пиратского софта. Да и вообще MS всю ответственность с себя за любые потери в EULA снимает.
А в closed-source кто-то что-то гарантирует или отвечает? См. крики людей по поводу того, что после установки SP2 на XP система перестала работать и отнюдь не из-за пиратского софта. Да и вообще MS всю ответственность с себя за любые потери в EULA снимает.
Есть стратегия развертывания ZeroCopy, она применима и к nix, она дает указанные гарантии и многие продукты так и ставятся…
По поводу гарантий, все зависит от заказчика 8) Кроме того, я знаю к кому обратиться за исправлением (телефоны\конкретные люди), а не писать на форумах «боже, что-то случилось и я не могу работать, как все вернуть назад?», что дает мне некое душевное спокойствие.
По поводу гарантий, все зависит от заказчика 8) Кроме того, я знаю к кому обратиться за исправлением (телефоны\конкретные люди), а не писать на форумах «боже, что-то случилось и я не могу работать, как все вернуть назад?», что дает мне некое душевное спокойствие.
Нет, ничего слететь не может, это я опечатался.
Пардон, моя ошибка, сейчас поправлю. Следует читать:
«ПО, устанавливаемое локально должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП)»
Смысл — гарантируется, что МП ничего не делает в иерархии /usr/local
Некоторая неуклюжесть из-за того, что это полиси — указания мэйнтенерам пакетов.
«ПО, устанавливаемое локально должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП)»
Смысл — гарантируется, что МП ничего не делает в иерархии /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) весьма много нюансов.
Отрицание 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 встречается копирайт 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 уже написали онлайновый дефрагментатор, а то люди жалуются на деградацию производительности со временем?
Как насчёт экспортирования 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 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/
Например.
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/
Хорошая заметка для начинающих. Почему нет?
Ну а чего тогда про MacOS не сказали? Там для пользовательских программ — первый вариант, для системных — второй
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
К вопросу о некоторых аспектах организации файловой системы UNIX/Linux