LINUX.ORG.RU

Убожество и безбожество, однакое. Зрю ересь и аз воздам за чистый конфиг безо всякого непотребства. Иже есть перекрестни, яко от безбожия норовят к богоугодию представится, им поелику документацию позновать, да поклоны чистому конфигу по три дря кряду в виме бить. А зело богомерзких виндузятников гнать взашей! Ибо позорят они читсую систему и на свой лад коверкают, адские сотоны! Анафему им, тычок в зубы и под зад коленкой. Ибо суть быть самим собой, а не последышами язычников всяких, кто сотворил себе из окон кумиры. Вдумайтесь грешники в слова мои и прозрейте - чистой, текставой конфиг он же ляпота есть и красота! Во веки аптайм и по ныне нот файл! # halt

Poh ★☆
()

Вот мой .emacs

(keyboard-translate ?\C-h ?\C-?)
(keyboard-translate ?\C-? ?\C-h)
;;Тут я пытаюст сделать так, чтобы при включенной руской раскладке ;;можно было перемешаться по буферам. Но не получилос. :(
;;(global-set-key (kbd "\C-ч") (lambda()(interactive)(insert "\C-x")))
;;(global-set-key (kbd "\щ") (lambda()(interactive)(insert "\o")))
;;
(global-set-key (kbd "\e\el") 'goto-line)
(add-hook 'c-mode-hook 'turn-on-font-lock 'font-lock-mode)
(add-hook 'cc-mode-hook 'font-lock-mode)
(add-hook 'nroff-mode-hook 'turn-on-font-lock 'font-lock-mode)
(global-font-lock-mode)
(add-to-list 'load-path "/home/ftp/soft/emacs/speedbar-0.14beta4")
(autoload 'speedbar-frame-mode "speedbar" "Popup a speedbar frame" t)
(autoload 'speedbar-get-focus "speedbar" "Jump to speedbar frame" t)
(define-key-after (lookup-key global-map [menu-bar tools])
[speedbar] '("Speedbar" . speedbar-frame-mode) [calendar])
(global-set-key [(f4)] 'speedbar-get-focus)
;; Texinfo fancy chapter tags
(add-hook 'texinfo-mode-hook (lambda () (require 'sb-texinfo)))
;; HTML fancy chapter tags
(add-hook 'html-mode-hook (lambda () (require 'sb-html)))
;; w3 link listings
(autoload 'w3-speedbar-buttons "sb-w3" "s3 specific speedbar button generator.")
(eval-after-load "info" '(require 'sb-info))
(add-to-list 'load-path "/home/ftp/soft/emacs/eieio-0.17")
(add-to-list 'load-path "/home/ftp/soft/emacs/semantic-1.4.4")
(setq semantic-load-turn-everything-on t)
(require 'semantic-load)
(add-to-list 'load-path "/home/ftp/soft/emacs/ecb-2.25")
(custom-set-variables
;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
;; Your init file should contain only one such instance.
'(ecb-options-version "2.25"))
(custom-set-faces
;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
;; Your init file should contain only one such instance.
)
(require 'ecb)
(setq auto-mode-alist
(cons '("\\.ml[iylp]?$" . caml-mode) auto-mode-alist))
(autoload 'caml-mode "caml" "Major mode for editing Caml code." t)
(autoload 'run-caml "inf-caml" "Run an inferior Caml process." t)

Предсавьте пожалуйста его реализацию с помощью реестра. Один вариант запостите сюда. Второй отправьте по почте RMS'у. Может ему понравится и он сделает emacs-23.0 с использованием реестра.

ugoday ★★★★★
()
Ответ на: комментарий от xhook

имхо, идиотизм каждую строчку в отдельный файл пихать. уж сделали бы как в java.util.Preferences...

marx
()
Ответ на: комментарий от anonymous

с LR придется копировать не один фалик, а целый каталог

marx
()
Ответ на: комментарий от Led

>> оно требует шуструю и ненадежную ReiserFS

> "ненадёжная" - голословное утверждение

Вот когда она отработает хотя бы лет 5 на куче машин (как ext2), тогда и будут неголословные утверждения. А пока она ненадежная. Мне от ФС стабильность нужна. Ext2 лично у меня с 1998 года работает. И не только у меня. А ReiserFS появилась недавно, поэтому доверия к ней нет пока.

> делаем loop-диск с reiserfs

Один большой XML-файл? :) Во где глюки-то пойдут. Не размонтировал его корректно, и пошел весь реестр в /dev/null.

Не ну я в курсе, что там не XML, но все равно, создавать ФС в файле и монтировать его через loop конечно можно, но только для некритичных данных. Ну типа имидж CD. А все настройки туда пихать -- ну его в болото.

И потом, мне же в /sbin/init придется прописывать, чтобы он сначала смонтировал этот файл, а уже потом лез за своими настройками в реестр. А это не есть хорошо, потому что сишный файл -- не скрипт, быстро его не поправишь.

nobody ★★
()

Как я рад, что местные пионеры, которые из-за своей близорукости в штыки принимают прогрессивные идеи... Так вот.. Как рад я, что они никак не влияют на развитие Linux и вообще технологий :)... Пусть кричат, а Linux Registry (название пугающее - заменят может быть) вполне возможно скоро уже будет в дистрибутивах, ибо рождается он кем-то из IBM.

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

>Как я рад, что местные пионеры, которые из-за своей близорукости в штыки принимают прогрессивные идеи...

будь добр прочитай этот пост -> ugoday (*) (13.08.2004 17:48:12)

Shadow_of_Pinguino
()
Ответ на: комментарий от Shadow_of_Pinguino

А кто сказал что миграция не затронет кода программы?

Наверное и внутри МС находились умники кричащие а нука мой .ini .cfg .bin представь в виде регистри

anonymous
()
Ответ на: комментарий от anonymous

>А кто сказал что миграция не затронет кода программы?

ну так на хрена надо перелопачивать стока кода - менять везде АПИ - ради какой то поделки-перделки ?

Shadow_of_Pinguino
()
Ответ на: комментарий от nobody

2nobody:

>Не размонтировал его корректно, и пошел весь реестр в /dev/null.

а зачем его размонтировать некорректно?

>только для некритичных данных. Ну типа имидж CD. А все настройки туда пихать -- ну его в болото.

аргументы (кроме "болото") будут?

>Вот когда она отработает хотя бы лет 5 на куче машин (как ext2), тогда и будут неголословные утверждения

вот когда буду неголословные утверждения - тогда и стОит их выражать, ИМХО...

>И потом, мне же в /sbin/init придется прописывать, чтобы он сначала смонтировал этот файл, а уже потом лез за своими настройками в реестр.

а initrd.img на что?

Led ★★★☆☆
()
Ответ на: комментарий от Led

Появился Linux Registry. Linux больше не нужин =)

anonymous
()
Ответ на: комментарий от Shadow_of_Pinguino

>ну так на хрена надо перелопачивать стока кода - менять везде АПИ - ради какой то поделки-перделки ?

Какое такое API? KtoVoChtoGorazd API?

LR втом числе и для того завели чтбы чтение конфигов было выполнено через общее осмысленное API а не через туеву хучу разничных вариантов и комбинация применения стандартных функций

zZzZ
()
Ответ на: комментарий от zZzZ

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

Найдётся дистрибутив, такой что ( (он будет использовать реестр) и (будет популярен) ). Пока что любой дистрибутив, такой что ( (он использует реестр) или (он популярен) или (он (не использует реестр) и (не популярен))).

Вот когда первое условие станет = true, тогда и поговорим о пользе реестра.

Далее, на мой предыдущий пост ответь. Если RMS тебе ответит, письмо сюда закоммить, будь добр. Очень интересно.

Кстати обратите внимание насколько круглые скобочки КРАСИВЕЕ угловых. Если RMS сделает в emacsе конфиги в виде одного большого xml файла ( и уберёт подсветку), то я нафиг уйду в vimeры.

Да, знаете почему ночной дозор воюет с дневным так непримиримо? Потому что ночной использует vim, а дневной -- emacs.

ugoday ★★★★★
()
Ответ на: комментарий от Shadow_of_Pinguino

И что? А зачем это пихать в реестр? Это часть emacs. Автокад по-твоему, свои базовые настройки на Автолиспе тоже в винюковом реестре хранит? Ты в своем уме? Чего вы, пионеры, все уперлись в идею пихать скрипты в реестр? Скрипты останутся скриптами, как и были. Только настройки они будут получать через вызов малюсенькой утилиты. А вот как - смотрите повнимательнее http://registry.sf.net

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

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

>И что?

Это настроечный файл emacs. Хочу знать во что это выльется при использовании новой технологии.

>А зачем это пихать в реестр?

Вот и я о том же. Реестр тут нафиг не нужен.

> Автокад по-твоему, свои базовые настройки на Автолиспе тоже в >винюковом реестре хранит?

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

>Ты в своем уме?

Ой, а в чьём?

>Чего вы, пионеры, все уперлись в идею пихать скрипты в реестр?

Пихать? Скрипты? В реестр? Да нафиг он нам вообще нужен?

>Только настройки они будут получать через вызов малюсенькой утилиты.

Ну уж нет. Болтать тут все горазды. Вы, прелесть моя, конкретную реализацию предложите.

>А вот как - смотрите повнимательнее http://registry.sf.net

Ты б ещё на гугль сослался.

>Уясните себе, что он не предназначен для хранения скриптов.

Он не был создан для жизни сей. Мир праху этому мертворождённому проекту.

А скрипты есть проверенный десятилетиями, удобный и мощный способ хранения конфигов. И нефиг от него отмахиваться.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Зачем миру был нуже еще один Unix в лице Linux?

zZzZ
()
Ответ на: комментарий от ugoday

Еще раз! (ох и устал же я с вас). Скрипты останутся скриптами! LR является не заменой скриптов, а подспорьем!

>А скрипты есть проверенный десятилетиями, удобный и мощный способ хранения конфигов. И нефиг от него отмахиваться

Ты говоришь "Кофиги как скрипты"? Да? А конфиг иксов - это тоже скрипт, а конефиг апача - это тоже скрипт? А fstab - это тоже скрипт? Да ты посомтри в /etс! Там скриптов - малая часть. В основном там полное месево из разноформатиных текстовых файлов. А проще говоря - помойка! Доступ к информации не унифицирован. Ты же, блин, не понимаешь своей же выгоды! Конфигурация emacs так и останется. Скрипты так и останутся. Но значения переменных будут братся не из тесктовым файлов, а фактически из файлов-ключей, но только содержащих эти значения. Если ты посмотришь, то скрипты, не надо будет сильно перелопачивать. И все это, кстати, не противоречит никаким юнихвэям, ПОСИХам и др. Это *не один XML-файл*!

Хочу отметить, что реализация в данном случае (в случае LR) действительно может быть подвергнута критике (мне тоже не все нравится - открыт вопрос применения какой-то избранной для этой цели FS, возможно). Я стою только за саму идею - *унификация доступа к настройкам программ (API)". Это, кстати, очень поможет в будущем привести в порядок /etc. Это поможет программистам не тратить свое время на написание своих парсеров для проверки правильности своих же конфигов и к простому доступу и управлению своими же настройками!

Я уверен, что результатом усилия по унификации /etc увенчаются успехом, потому что это многим нужно. И потом вы сами почувствуете от этого пользу. И еще уверен, что ситуация, когда очень многие охаивали эурналируемые FS здесь, а потом стали говорить, что это круто (а дело-то реально было. Я помню эти баталии) повторится...

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

> Еще раз! (ох и устал же я с вас). Скрипты останутся скриптами! LR является не заменой скриптов, а подспорьем!

Скорее не споря, а соглашаясь и комментируя общую ситуацию, нажимаю кнопку ответить здесь... ;-)

Начнём с Win-реестра. Тут многие красноглазики (по иному - не назовёшь), сочли своим святым долгом отметится на этом поприще, показав, как всегда непроходимую дремучесть. То, что "поделие" одной фирмы давным давно имеет пермишшоны им уже объяснили. Сейчас добавим. Win-реестр - не монолитен. Корневые ключи лежат в разных файлах, например, CURRENT_USER - вообще в профиле пользователя, что облегчает процедуру копирования профиля целиком... Что там ещё было? Доступ? Так вот, форточный реестр прекрасно доступен по сети и тоже с правами. Ну ладно, что это мы всё об оффтопике, да об оффтопике. А нет, ещё осталось. Кто тут про дотНЕТ кричал? Хотите конфиги и экзешник вместе слить? Так, кто тут самый горластый? Ты? Нет, мне из тех нужен, кто про unix-way любит орать. Ты? Отлично, подходи, становить, набирай воздуха в грудь и кричи. Что кричать? Разумеется, не unix-way! Почему? А сам посуди, как требует unix-way - конфиги в etc, софт в usr, рабочие файлы в var. А тут всё в одно слить предлагают! Ай! Зачем же орать-то так! Беруши мне, беруши! Вот, две штуки в рот и запить водичкой, теперь по-легче стало...

Вернёмся к linux'у наконец. Собственно, вопрос с редактированием упирается лишь в консольный интерфейс. Он не обязательно может быть утилитным, например модуль к mc... Самое главное, что кое-кто упорно мешает тёплое и мягкое, т.е. есть потребности и удобства сервера (и то, администрирование на LDAP перетаскивают, а это не проще реестра!) и потребности десктопа. Вот там-то как раз текстовые конфиги - зло. Ибо если уж начали работать с GUI, то самое худшее - это полумеры. Пародия на десктоп получается, ибо там-то как раз всё "рюшечками" надо рулить. По крайней мере - основные вещи. Тут-то собака и порылась - одно дело распарсить сложный конфиг на чтение и совершенно другое, вставить новое значение на место старого, не покорёжив никаких комментариев, читабельность сохранив. А если там переносы "\" использовались? Не невозможно, но... Вот потому до сих пор и ругают утилиты-конфигураторы. Что ещё... А! Кто там "прикалывался" насчёт "потребуется перезагрузка"? Интересно, а в форточках, после регедита, предлагали грузится? Мне - нет. А если использовал нормальное приложение, с рюшечками, то оно и должно знать кому SIGHUP посылать... Что там дальше? Захламление? А вы думаете у вас так помойка не скапливается? Все эти .rpmnew, .rpmsave, .bak'и, которые сами делаете, когда в сложном конфиге изнемения наводите, а потом оставляете, чтобы убедится, что изменения работают. Только вот нет ничего более постоянного...

Просто удивительно, что никто не смог сесть, прикинуть и понять, что у реестра плюсов ровно столько же, сколько и минусов. Ни больше, не меньше, а ровно столько же. Но ещё больше смеха вызывает то, что те, кто успешно озаял реестр только за название, кто ухитрился одновременно изойти на пену и на Г. Кто бесконечно повторял друг дружке шутку про xml, не перествая хихикать над ней, подобно Бивису и Батхеду... Вообщем, не смогли назвать главный минус - реестп делается под linux, а софт, особенно достаточно мощьный и популярный - под unix, т.е. не понятно, чем будут завлекать разработчиков на него, т.к. поддерживать две системы конфигурирования - накладно. Разве что Novell волевым решение GNOME пересадит. Да и то - неизвестно, будет ли от этого лучше. Но то, что GUI'ёвинам подобная вещь нужна как воздух - факт.

atrus ★★★★★
()
Ответ на: комментарий от Zubok

Давайте подождем реализации проекта. Может кто-нибудь дистрибутив с применением LR сваяет (не с нуля конечно, просто переделает готовый дистриб), вот тогда и посмотрим. А пока я не могу себе представить, как можно сделать юникс с общим реестром, и не потерять в надежности, простоте и удобстве (что-бы там не говорили, а обычный, с хорошими комментариями конфиг править мне удобнее, чем структурированный файл с иерархией (даже с использованием специального софта а-ля regedit.exe, или с примочкой к vim/emacs)).

Сейчас дистрибутивы разделяют по типу инициализации (BSD/SysV) и системе управления пакетами (RPM/DEB/TGZ(слака)/portage(FreeBSD, Geento)). Возможно, в будущем будут разделять дистрибутивы по системе хранения настроек (реестр/обычные конфиги). Будет хорошо, если RH перейдет на реестр, а остальные останутся на конфигах (RH любит эксперименты) -- тогда мы увидим, чего этот LR стоит.

Анализируя опыт MS Windows: вначале реестр может показаться хорошим и удобным решеним, в сравнении с обычными конфигами (в win3.11 использовались конфиги win.ini и system.ini, а в win95 появился реестр. Ковыряясь в нем тогда я подумал: "Как это удобно. Все в одном месте, стандартизированное и доступное для всех программ". Винда развивалась, настроек становилось больше, появились всякие программы для настройки виндуза. Винда была нестабильна, но это было из за несовершенства ядра системы (фактически винда была лишь сверх-развитой графической средой для ДОСа, и от ДОСа получила в наследство низкую стабильность). А потом стала постепенно набирать популярность среди простых юзеров семейство Windows NT (WinNT>Win2000>WinXP). У NT использовала свое ядро, не совместимое с ДОСом (постепенно ДОСовские программы отошли впрошлое) и изначально ориентированное на серверы. В результате ветка NT (nt,2k,xp) была на порядок стабильнее ветки 9x (95,98,me). 9x многие использовали из за низких системных требований и хорошей поддержки игр. Многие игры нормально работали в win2k, а в winXP поддержка игрушек стала такой хорошей, что почти все стали играть в игры под XP. Win2000 или XP довольно стабильная ситема (не как юникс конечно, но стабильная): весь день ее можно довольно активно использовать и она не повиснет. Вроде бы все хорошо? Или...

...Итак, представьте (те кто достаточно знакомы с виндой): winXP (или win2k) грохнулась. Как это произошло? Установили кривой драйвер на важное устройство, или случайно (специально) случился перезагруз компьютера (падение напряжения в сети, нажатие кнопки RESET). Итак винда грузится и показывает синий экран смерти, на котором написано что-то непонятное: кракозябры вместо русских букв, шестнадцатиричные коды... В лучшем случае будет написано имя модуля, вызвавшего ошибку (ati.vxd, например (драйвер видюхи) и можно будет понять что именно заглючило. Что можно сделать? Попробовать загрузить винду в "safe-mode" (помогает редко). Восстановить систему из бэкапа? Если бэкап есть, а если его нет?... Спасать то систему надо... Грузимся с загрузочного сидюка, запускаем установку винды, из установки "консоль восстановления" (recovery console). Запускается командная строка с очень ограниченными возможностями (внешние программы запускать нельзя!), которых хватает только на гурбый ремонт (загрузочник винды в MBR впихнуть например). Ни о какой работе с реестром речи не идет вообще. Все, абзац. Лечиться переустановкой винды (кучу программ приходится переустанавливать, а у тех которые не надо, сбросились настройки, которые хранились в реестре) либо вытаскиванием реестра из какого-нибудь бэкапа. Как видите речи о том, что-бы исправить неисправность руками, не идет, так как даже если открыть в каком-нибудь редакторе реестра (например на другой машине с виндой) реестр, то разобраться в этом хитросплетеньи ключиков, и корректно решить проблему с кривыми драйверами вряд ли получиться. То есть реестр современной винды представляет из себя такую помойку, в которой в случае чего не разберешься (или это потребует значительно больших усилий и знаний, чем, например, подъем линукса).

Нафиг я все это написал?... Ах да, резюмирую: если LR приживется, то есть вероятность, что через несколько лет мы получим глючную помойку огромного размера, разобраться в которой будет намного сложнее, чем в обычных текстовых конфигах. Примеры проблем "а какой именно ключ реестра отвечает за настроку <того-то>?", "откуда берутся ТАКИЕ настройки в /proc/<что-нибудь>", "а что это за непонятный ключ реестра с непонятным названием и без всяких комментариев?", "Черт! Какая программа исправила значение вот этого ключа?". Следить за кучей конфигов легче, чем за реестром.

Выработка единого стандарта на конфиги, что-бы всем удобнее было? Я не против, но какого черта нужно пихать все в реестр? Неужели просто нельзя написать рекомендации?

Да, когда все максимально стандартизированно -- это удобно. Но когда от этого зависит надежность системы (а в том, что надежность понизится вроде бы сомнений нет?), то я выберу обычные конфиги, потому что в этом случае программы меншь зависят друг от друга (если я испортил конфиги X-window, то накрылись только иксы, а все консольное продолжает работать).

В случае с реестром все получается взаимосвязанно: например есть ключ, в котором прописанна особенная модель поведения для кучи программ. Вы случайно сделали ошибку при редактировании этого ключа, и все программы, берущие информацию из него в лучшем случае работают некореектно (в худшем -- чего-нибудь портят). Вот представьте: стоит сервак с реестром (уже смешно?) и регулярно качает обновления и их ставит. При этом обновляются не только /usr/ но и /etc/registry (или что там будет). Нелепая ситуация, верно? ;)

(Я прошу прошения за сумбурный текст и орфографические ошибки -- спать хочется. Дописываю и ложусь)

Когда настройки программ независимы друг от друга, то при серьезных изменениях в настройках одной из них (допустим, вы вручную переписали конфиг), на другую программу это никакого воздействия не оказывает. Если все взаимосвязанно, то возникает коммулятивный эффект: из за одной программы глючит другая, из за другой -- третья, и что бы докопаться до сути (что послужило причиной глюка), потребуется много усилий.

Вобщем, у реестра есть плюсы (унификация настроек, все в одном месте, выглядит похоже, поменял один ключ -- и это подействовало на кучу программ) есть и минусы, порожденные взаимосвязанностью всех настроек.

Мне это напоминает ситуацию, когда одна единственная переменная, (LC_ALL, например) при неправильной настройке способна сделать неработоспособной кучу программ.

Harliff ★★★★★
()
Ответ на: комментарий от Harliff

> Примеры проблем "а какой именно ключ реестра отвечает за настроку <того-то>?", "откуда берутся ТАКИЕ настройки в /proc/<что-нибудь>", "а что это за непонятный ключ реестра с непонятным названием и без всяких комментариев?", "Черт! Какая программа исправила значение вот этого ключа?". Следить за кучей конфигов легче, чем за реестром.

Подмена понятий. Неявно предполагается, что в конфигах-то комментарии есть; в то же время в LR комментарии являются частью спецификации. Если комментарии есть и там и там, то разгрести реестр будет не сложней чем конфиг.

int19h ★★★★
()
Ответ на: комментарий от Harliff

> Мне это напоминает ситуацию, когда одна единственная переменная, (LC_ALL, например) при неправильной настройке способна сделать неработоспособной кучу программ.

Позвольт не согласиться, программы не становяться неработоспособными, скорее не читабельными. Взять хотя бы тот же mc, работать можно но как 8-)...

А вот то что все придёт туда куда нам кажет дядя БГ так это даже очень модет быть. Получется хотели как лучшше а полчилось как у мелкомягких.

И ещё почему никто не спомнил формат конфигов КДЕ, я щитаю очень удачным сочетанием структурированности и читабельности.

cyclon ★★★★★
()
Ответ на: комментарий от Harliff

> Ах да, резюмирую: если LR приживется, то есть вероятность, что через несколько лет мы получим глючную помойку огромного размера, разобраться в которой будет намного сложнее, чем в обычных текстовых конфигах.

Обязательно получим! При отсутствии централизованной разработки оного.
И несовместимость дистрибутивов. Ага.

> Выработка единого стандарта на конфиги, что-бы всем удобнее было? Я не против, но какого черта нужно пихать все в реестр? Неужели просто нельзя написать рекомендации?

У-у! Так это сколько организационной работы нужно провести. Не, тебе щас реестр впарят - типа панацея.

> Да, когда все максимально стандартизированно -- это удобно.

А кто спорит? Только почему-то реестрологи полагают, что стандартизация сама собой получится.

PitStop
()
Ответ на: комментарий от atrus

2zZzZ

>зачем миру был нуже еще один Unix в лице Linux? man just_for_fun, там всё написано.

2Zubok

>Да ты посомтри в /etс! Там скриптов - малая часть.

Сколько ни есть, а все мои.

> А проще говоря - помойка!

В этой "помойке" порядка гораздо больше, чем в маздайном реестре.

>Доступ к информации не унифицирован.

Как программа работает со своим конфигом это есть персональное сексуальное дело этой программы, и меня как админа, они ниразу не интересуют. Меня интересует, как я буду править этот конфиг. И есть унифицированный инструмент -- emacs. Уж ручками то проще править нормальный текстовый файл, в хорошем тектсовом редакторе, чем разбросанную по директориям сотню однострочников.

>Ты же, блин, не понимаешь своей же выгоды!

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

>Конфигурация emacs так и останется. Скрипты так и останутся

Вот тут вы правы. И нормальные конфиги, и скрипты так и останутся. А поделка по имени "реестр", скоро всем надоест (где-то через 2-3 новости) и её забросят за ненадобностью.

Кстати, господа. А может и нет никакого реестра? Просто какой-то приколист сайтик сваял, скриншоты в гимпе нарисовал, а потом постит новости на лоре и прётся с флейма?

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

Ну и зачем всё это? Чем сложнее система, тем больше вероятность отказа, и тем сложнее восстановление после краха и поиск ошибок.

>Это *не один XML-файл*!

Верно, не один. Это там их тысяча.

>Я уверен, что результатом усилия по унификации /etc увенчаются >успехом, потому что это многим нужно.

Это не нужно никаму, кроме писателей автоконфигурялок. И сколько их от общего числа пользователей?

>И потом вы сами почувствуете от этого пользу.

Не, пусть мы сейчас почуствуем выгоду, а потом перейдём на реестр.

2atrus

>Начнём с Win-реестра

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

>Win-реестр - не монолитен.

А /etc ещё не монолитнее.

>Так вот, форточный реестр прекрасно доступен по сети и тоже с >правами.

С юниховыми конфигами всё тоже самое. Ваши утверждения доказывают только, что win-рестр, не абсолютное говно, но не показывают его преимущества над /etc. Кроме того, afaik, это всё появилось только в w2k, тоесть на *дцать лет позже чем у *никсов.

>Кто тут про дотНЕТ кричал? Хотите конфиги и экзешник вместе слить? >Так, кто тут самый горластый? Ты? Нет, мне из тех нужен, кто про >unix-way любит орать. Ты? Отлично, подходи, становить, набирай >воздуха в грудь и кричи. Что кричать? Разумеется, не unix-way! >Почему? А сам посуди, как требует unix-way - конфиги в etc, софт в >usr, рабочие файлы в var. А тут всё в одно слить предлагают! Ай! >Зачем же орать-то так! Беруши мне, беруши! Вот, две штуки в рот и >запить водичкой, теперь по-легче стало...

Вы всегда так "понятно" разговариваете? Знаете, ваш поток сознания просто великолепен. Только, если хотите быть понятыми, постарайтесь свою речь структуировать, или наймите переводчика.

>и потребности десктопа.

Определение десктопа в студию.

>Вот там-то как раз текстовые конфиги - зло.

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

>Ибо если уж начали работать с GUI,

Почему это начали? Мы с гуем уже давным давно работаем.

>Пародия на десктоп получается, ибо там-то как раз всё "рюшечками" >надо рулить

Дикарям нужны рющечки и цветные бусы. Белому человеку нужны функционал и удобство.

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

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

>А вы думаете у вас так помойка не скапливается?

Нет, не скапливается. Чистилки реестра есть? Есть. А хоть одну чистилку /etc или ~ назвать сможете? Имхо это означает, что реестр захламляется, а тектсовые конфиги -- нет.

>Просто удивительно, что никто не смог сесть, прикинуть и понять, что >у реестра плюсов ровно столько же, сколько и минусов.

А если плюсы уравновешивают минусы, значит пользы от перехода на реестр нет.

>Вообщем, не смогли назвать главный минус - реестп делается под linux, >а софт, особенно достаточно мощьный и популярный - под unix,

Вроде ж было, ещё в первом обсуждение. Кстати, и как вы предлагаете решить эту проблему?

>Но то, что GUI'ёвинам подобная вещь нужна как воздух - факт.

Да ну? Без воздуха я за 5 минут загнусь. А без реестра два десятка лет с гаком живу и ничего. А даст Патрик, ещё два раза по столько проживу и всё без реестра.

2Harliff

>Давайте подождем реализации проекта.

Долго ждать придётся.

>То есть реестр современной винды представляет из себя такую помойку >...

Имхо, главное даже не то, что реестр -- помойка, а то что он не задокументирован. Там куча левых ключей с нечитаемыми названиями и совершенно дикими значениями. Тогда как хорший конфиг самодокументируемый.

ugoday ★★★★★
()
Ответ на: комментарий от atrus

> Win-реестр - не монолитен. Корневые ключи лежат в разных файлах, например, CURRENT_USER - вообще в профиле пользователя, что облегчает процедуру копирования профиля целиком...

Равно как и его потерю. Не раз наблюдал как погибший ntuser.dat не давал даже прилогиниться! А если я его не бэкапил, то как мне его восстановить ? И почему это не предлагает сделать сама система при загрузке? Чем сложнее копировать профиль пользователя в linux по сравнению с ntuser.dat?

PitStop
()
Ответ на: комментарий от int19h

>Неявно предполагается, что в конфигах-то комментарии есть;

Так они там действительно есть. Более того, описания конфигов есьт в манах. (man lilo.conf, например) Чего за реестром не замечено. И вообще, зря эту приблуду назвали реестром.

2PitStop

>Так это сколько организационной работы нужно провести.

Да пофиг. Главное кому тогда лавры спасителя отечества от /etc hella достанутся.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

> Да пофиг. Главное кому тогда лавры спасителя отечества от /etc hella достанутся.

Дык и я про то же! Вместо того чтобы делом (привести в порядок etc не меняя сути) заняться, непростым весьма, занимаются ерундой. Избавители хреновы. А потом, когда всё это станет большим глюкалом скажут что "вы сами виноваты" и т.п. Мы то белые и пушистые, а вы нашу светлую идею загубили.

ps Добавлю, что всякого рода автоматизация имеющегося бардака приводит к печальным результатам. И средства автоматизации лишь увеличивают его. :-(

PitStop
()

Вот впишут в LSB и не будет предполагаемого бардака

А так речи противников похожи на речи кучеров про автомобили

zZzZ
()

Опять начинается. Надоело мне уже отвечать в темы про LR. Буду спрашивать. Итак:

10 РИТОРИЧЕСКИХ ВОПРОСОВ

1. Что такое толерантность?

2. Слышали ли вы про утилиты и библиотеки autoconf, automake, libtool, intltool, gettext, iconv, getopt?

3. Всегда ли удобно их использовать?

4. Универсальны ли эти утилиты и библиотеки?

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

6. Какова в целом динамика (использование/отказ от использования) в том, что касается этих утилит и библиотек?

7. Зачем существуют стандарты POSIX, SUS и т.д.?

8. Что обеспечивает сырцовую (и, отчасти, бинарную) совместимость между UNIX-программами в системах на разных платформах и на разных ядрах?

9. Кто виноват?

10. Что делать?

eyescream
()
Ответ на: комментарий от eyescream

2eyescream

1. Спроси у Антихриста. Он тут лучше всех знает, что такое гуманизм и толерантность.

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

3. Нет.

4. Нет.

5. Да.

6. Большинство использует autoconf.

7. Чтобы выполнялся пункт 8.

8. Выполнение пункта 7.

9. ESR. Поясню, если б он активнее вёл разъяснительную работу, то всевозможные подбилгейтсовики и сексоты майкрософт просто не могли бы затясаться в наши ряды. :)

10. Заняться делом, а не прожекты составлять.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

Постановка вопроса именно такая.

> Но LR это ниразу не autoconf. Он скорее похож на ещё один самопальный текстовый редактор.

Это который из них - vi или emacs? =)

> Заняться делом, а не прожекты составлять.

Прожекты составляют на ЛОРе, а эти люди как раз пишут LR =) Хотя, честно говоря, что-то медленно пишут.

int19h ★★★★
()

2 Harliff:

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

etc - уже помойка. Кстати, не вижу причины, по которой lin-реестр разростался бы. Собственно, больше чем etc (по объёму хранимой информации ему быть не светит)...

> Примеры проблем "а какой именно ключ реестра отвечает за настроку <того-то>?"

А когда я пересел с форточек на linux, первые полгода я бегал по граблям и матерился, а в каком [censored] конфиге прописывается это... Кстати, LR - комментарии поддерживает, специально для незнающих/непомнящих...

> Выработка единого стандарта на конфиги, что-бы всем удобнее было? Я не против, но какого черта нужно пихать все в реестр? Неужели просто нельзя написать рекомендации?

Хм... Одного стандарта мало. Если каждый сам будет делать реализацию, то будет как с MIDI и CORBA - стандарт есть, а совместимости нет. Тут главная ценность не в самих конфигах, а в общей библиотеке, которая не только чтение, но и запись поддерживает.

> Да, когда все максимально стандартизированно -- это удобно. Но когда от этого зависит надежность системы (а в том, что надежность понизится вроде бы сомнений нет?)

Сомнения есть. Стандартизация/Структуризация - единственный способ управлять большими системами. Давайте какждый дистр станет лепить как ему хочется, всё такое гибкое станет и совместимое!

> Вы случайно сделали ошибку при редактировании этого ключа, и все программы, берущие информацию из него в лучшем случае работают некореектно (в худшем -- чего-нибудь портят).

В сделали ошибку, редактируя cfg-файл и все программы, берущие информацию из этого конфига "лучшем случае работают некореектно". Найдите, что называется 10 отличий.

> Вобщем, у реестра есть плюсы (унификация настроек, все в одном месте, выглядит похоже, поменял один ключ -- и это подействовало на кучу программ)

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

> Только почему-то реестрологи полагают, что стандартизация сама собой получится.

Я не жду от реестра никакой стандартизации. У него один существенный плюс - возможность относительно лёгкого и безопасного конфигурирования утилитами, а не вручную.

2 ugoday:

> В этой "помойке" порядка гораздо больше, чем в маздайном реестре.

Ты просто не прав. В "маздайном" всё зашкурено, покрашено, просеяно песком. Помойка там появляется только после левых программ. Но от этого и etc не застрахован...

> С юниховыми конфигами всё тоже самое. Ваши утверждения доказывают только, что win-рестр, не абсолютное говно, но не показывают его преимущества над /etc.

Гениально! Ты меня понял! Именно это я и говорил. Реестр - не хуже и не лучше /etc. Но они разные. Там где слаб один - силён другой и наоборот.

> Вы всегда так "понятно" разговариваете? Знаете, ваш поток сознания просто великолепен.

Извини, я забыл, что на ЛОРе. Тут народу надо по простому, матерком. Это ведь проще понять...

> Неочевидно. Объясните почему. На моём десктопе текстовые конфиги -- благо.

Подозреваю, что у тебя не десктоп, а виндоумейкер. Собственно, то что у тебя благо - не значит, что оное же благо для всех. Собсвенно, я заинтересован в широком распространении линукса, а это значит, что 20% (самых часто используемых) фич должны конфигурятся вообще через менбшки и чекбоксы.

> Если для программиста это является неодолимо сложной задачей, пусть переквалифицируется в дворники.

Вероятно ты - суперпрограмист. Я вот делал либу, поддерживающую конфиги в ситле апача. Причём потокобезопасную и с поддержкой записи. Причём так, что бы не корёжило комментарии и т.д. Так вот, сделать обратную запись было на порядок труднее, чем парсинг параметров. Ксати, при прямом парсинге - о типе параметра приходится вообще догадываться. А теперь представить, что в DE нам надо вставить конфигурялки не только к апачу, но к десяткам софтин, конфиги которых только человеку кажутся похожими. И, спрашивается, на что будет уходить время разработчиков?

> Чистилки реестра есть? Есть. А хоть одну чистилку /etc или ~ назвать сможете?

Хех. Это потому, что не смотря на хвалёные скрипты линксоиды делают это по прежнему вручную! ;-)

> Вроде ж было, ещё в первом обсуждение. Кстати, и как вы предлагаете решить эту проблему?

Да? Пропустил... ;-) А никак не предлагаю, не решаемая она, т.к. теже фри принципиально не будут связыватся с LR. Соответсвенно, или от него откажутся и мы поимеем черепашьи темпы развития десктопа или кто-то предложит использовать его паралельно, тогда какое-то время будет возможность делать и так и так, но потом все подсядут на LR, а остальные *nix останутся на бобах...

> главное даже не то, что реестр -- помойка, а то что он не задокументирован

Уверяю тебя, он задокументирован. Просто эту инфу не преподносят на тарелочке, а продают... Но это же WR. Не обязательно повторять все его ошибки? ;-)

2 PitStop:

> Равно как и его потерю. Не раз наблюдал как погибший ntuser.dat не давал даже прилогиниться! А если я его не бэкапил, то как мне его восстановить ?

Никак. Переименовать папку с проыилем и войти в систему, что бы новая создалась. А потом (поскольку в CURRENT_USER хранятся персональные настройки) запустить все проги, что бы они создали новые. Или переставить/скопировать с другого профиля. А что ты будешь делать если у тебя /home глюканёт?

Кстати, при сносе проге на linux в /home настройки остаются. Так что в linux просто помойка не в реестре и даже на в /etc, а просто в /home перенесена... Так что... ;-)

2 zZzZ:

> А так речи противников похожи на речи кучеров про автомобили

tnx... ;-)

atrus ★★★★★
()
Ответ на: комментарий от int19h

>Постановка вопроса именно такая.

Ничего подобного. Эти граждане революцию творят и славу зарабатывают. Разрушают до основанья работающую, отлаженную систему, и обещают потом светлое будующее.

По уму, стандартизацию /etc надо проводить так:

1. подумать;

2. подумать;

3. подумать;

4. поговорить с мантейнерами разных дистрибутивов (это ведь им потом пакеты собирать);

5. подумать;

6. предложить стандарт, такой что:

а. конфиги удобно править ручками;

б. легко научить автоконфигурялку работать с данным форматом конфигов.

в. данный формат подходит для большинства приложений.

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

7. написать либу, предоставляющую апи к данным конфигам (типа getvalue, setvalue)

8. создать дистрибутив на основе этого формата конфигов.

Если пункт 8 будет пройден успешно, то данная фича войдёт в жизнь, не раньше.

Что мы видим в данном случае. Пункты 1-3, 5 выполнены небрежно. Про пункт 4 ничего не скажу, не знаю. Пункт 6.а не выполнен совершенно, что ставит крест на этой приблуде. Пункт 6.б выполнен хоршо, что однако проект не спасает. 6.в выполнен плохо. 6.г выполнен отвратительно. пункт 7 вроде выполнен. Пункт 8 не выполнен вообще.

Имхо, если уж приспичило сделать единый формат конфигов, то пусть это будет скрипт-конфиг на лиспе. (термин скрипт-конфиг употреблён из-за неотличимости кода и данных). Его и руками править легко и парсилка для лиспа пишется элементарно и подходит он для всех случаев и масштабируем до жути (от убогого key=value, до всей мощи формализма рекурсивных функций).

Кстати, на лоре прожекты не составляют. Здесь обсирают уже составленное.

ugoday ★★★★★
()

Ну что вы уперлись все в vi и emacs. Оставте их в покое? Будет для реестра свой консольный редактор. Причем он будет маленький (меньше, чем vi), удобный, функциональный. Он легко влезет на дискетку. Кто не захочет этим пользоваться, то тот сможет использовать маленькую утилиту, прототип которой уже есть на http://registry.sf.net

Реализаций единого хранилища конфигураций уже предложено несколько (учитывая и ананимусные): Вот можно их систематизировать. У каждого есть плюсы и минусы. Эти минусы и плюсы может каждый для себя определить.

1. Один XML-файл. Этот способ реализаций, пожалуй, самый бестолковый и опасный. До такого не дойдет.

2. Варианты из класса "системы иерархических текстовых файлов"

2.1. Несколько XML-файлов (как GConf). Хотя XML пугает. И надо с собой распарсивалку таскать и все-таки руками править *.xml мало удовольствия. 2.2. Несколько файлов типа *.ini. гораздо удобнее править при желании руками при помощи того же emacs/vi/joe and etc. Я не видел конфигурационных файлов KDE, но насколько я понял, идея похожая - простой, удобный для чтения иерархический файл без всяких XML. 2.3. Кто-то тут раньше предлагал использовать файлы типа ресурсников иксов. Да, это тоже вариант, но править руками менее приятно, потому что для каждого параметра надо повторять путь к нему. Если глубокая иерархия, то это особенно неприятно. Да и допустить ошибку легко.

3. Вариант из класса "Файл-свойство". К этому способу принадлежит как раз LR. Хорошо то, что к каждому свойству можно определить права доступа (возникает, правда, вопрос, насколько это нужно). Да и потом часть реестра можно хранить и в /home у пользователей. Здесь хорошо то, что доступ к конфигурации достигается опять стандартными методами - открытие текстового файла. Поэтому в описании LR и указывается, что данное решение может использоваться даже для особо важных утилит типа mount.

В GConf вообще реализация сделана так, что можно сменить способ хранения конфигурации. Можно хранить в виде "файл-свойство", можно в виде набора xml, можно LDAP and whatever you want. В GConf пугает многих (вполне справедливо) то, запускается некий демон gconfd. Это не надежно, поэтому GConf предлагается пока только для GNOME desktop, а не как system-wide решение. Но зато GConf умеет отслеживать изменение значения ключа и сообщить об этом приложению. В десктопных приложениях это очень удобно. Однако думаю, и для LR можно придумать такой демон. Как опцию для десктопных приложений. Запустить его, сказать ему: "Следи, сволочь вот за этими ключами!".

Есть еще реализация GNU4Conf (кажется так называется).

Каждый вариант реализации хочет стать признанным. Кому-то вполне может повезти и он попадет в LSB.

Zubok ★★★★★
()
Ответ на: комментарий от Harliff

>Вобщем, у реестра есть плюсы (унификация настроек, все в одном месте, выглядит похоже, поменял один ключ -- и это подействовало на кучу программ) есть и минусы, порожденные взаимосвязанностью всех настроек.

Как раз LR такую фишку не умеет делать. Это не активное, а пассивное хранилище. Для этогонадо демон некий придумать и придумать еще систему колбэков под это дело. То есть как сообщить прикладухе об изменениях. Вот GConf это умеет, но для этого приложение должно уметь работь с GConf. Пока этотолько мейнстрим для GNOME. А пока приложениям придется самим или по команде от пользователя перечитывать конфиг (перезапуском, при помощи заложенных для этого специальных ключей командной строки, периодически перечитывать)... Кто-то это будет уметь, кто-то нет.

Zubok ★★★★★
()
Ответ на: комментарий от atrus

2atrus

>Кстати, не вижу причины, по которой lin-реестр разростался бы.

А я не вижу причины, по которой win-реестр разростался бы. А он берёт и разростается. Сволочь глазастая.

> Собственно, больше чем etc (по объёму хранимой информации ему быть >не светит)...

Уж по количеству файлов реестр etc точно превзойдёт порядка на два.

>А когда я пересел с форточек на linux, первые полгода я бегал по >граблям и матерился, а в каком [censored] конфиге прописывается >это...

Дык, всё правильно. Сначала человек учится, а научившись спокойно работает. Это везде так от сантехников до математиков.

>В "маздайном" всё зашкурено, покрашено, просеяно песком. Помойка там >появляется только после левых программ. Но от этого и etc не >застрахован...

Т.е. чтобы в мазадайном реестре был порядок надо просто не устанавливать в систему прикладное по. Вот замечательяная система конфигурации софта! Не ставьте программ и у вас будет полный пиз^D^Dорядок! А etc уже тем застрахован от левых программ, что в репозитарии дистрибутива уже есть программы на все случаи жизни. И левых программ ставить просто не надо. А вот в маздае без них не обойтись.

>Там где слаб один - силён другой и наоборот.

Фишка в том, что для меня (для меня _лично_) сила реестра в автоконфигурялках неинтересна, а слабость в ручной правке критична. Т.е. _лично_ для меня минусы реестра значительно перевешивают его плюсы.

>Подозреваю, что у тебя не десктоп, а виндоумейкер.

Блять! Ж8-) Как ты догадался?

>Собственно, то что у тебя благо - не значит, что оное же благо для всех.

И наооборот.

>Собсвенно, я заинтересован в широком распространении линукса,

А я заинтересован, чтобы было удобно _лично_ мне. Вот такой я безыдейный эгоист. Но удоство работы для меня гораздо важнее world domination.

> а это значит, что 20% (самых часто используемых) фич должны >конфигурятся вообще через менбшки и чекбоксы.

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

>Я вот делал либу

На чём, если не секрет?

>А теперь представить, что в DE нам надо вставить конфигурялки не только к апачу

>И, спрашивается, на что будет уходить время разработчиков?

Берётся уже готовая гнутая парсилка. И всё.

>Хех. Это потому, что не смотря на хвалёные скрипты линксоиды делают >это по прежнему вручную! ;-)

Дык, я конфиги правлю вручную. Откуда ж там мусор возьмётся? Ну а если чего набедокурю, так вручную же и исправляю.

>А никак не предлагаю, не решаемая она

И вы всерьёз предполагаете, что удобство написание самоконфигурялок, оправдывает ломку скриптовой совместимости между юниксами? Тут за башизмы канделябрами по мордам бьют, а за такое вообще кастрируют тупыми ножницами. Кстати кто знает сколько метана (кубометр / килограмм) можно получить из одного человека?

>Уверяю тебя, он задокументирован.

Если инфа есть,но доступа к ней нет, значит инфы нет.

>А что ты будешь делать если у тебя /home глюканёт?

А хрен его знает, ниразу не видел, чтобы /home глючил.

>Кстати, при сносе проге на linux в /home настройки остаются.

Это возникает только если перед сносом проги выполнить от рута

# ln -s /dev/ass /dev/hand

Вкаком пакетном манагере наблюдаются такие проблемы?

>> А так речи противников похожи на речи кучеров про автомобили

>tnx... ;-)

Господа, вы читали "Путешествие Гулливера" в полном (т.е. неадаптированном) виде. Нахуя апач на десктопе? Нет, ну серьёзно, зачем он там?

ugoday ★★★★★
()
Ответ на: комментарий от Zubok

> 3. Вариант из класса "Файл-свойство". К этому способу принадлежит как раз LR. Хорошо то, что к каждому свойству можно определить права доступа (возникает, правда, вопрос, насколько это нужно). Да и потом часть реестра можно хранить и в /home у пользователей. Здесь хорошо то, что доступ к конфигурации достигается опять стандартными методами - открытие текстового файла. Поэтому в описании LR и указывается, что данное решение может использоваться даже для особо важных утилит типа mount.

4. Файлы нескольких стандартизированных типов, разложенные по дереву каталогов, и единый стандартный API для доступа к ним (но его использование необязательно). Типы файлов:

а) PARAM = VALUE

б) *.ini

в) *.xml ;-)

г) /etc/inittab

д) /etc/passwd

и т.д., для всех стандартов de-facto (их немного...). Вот таким и должен быть LR (IMNSHO). Кто против? Кто за?

Yampp
()
Ответ на: комментарий от Yampp

Дык сейчас так и есть. Кто как хочет, тот так и хранит свои конфиги. И это правильно.

А типов конфигов действительно немного. Только, имхо, лучше такая классификация ((исполняемые (sh lisp perl любой_интерпретируемый_язык)) (неисполнеемые (а б в г д)) )

2Zubok

>Будет для реестра свой консольный редактор

Вот только ещё одного редактора для полного счастья не хватало.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

> А я не вижу причины, по которой win-реестр разростался бы. А он берёт и разростается. Сволочь глазастая.

В привидения я не верю, значит объективная причина есть. Но проблемы win реализации не обязательно воспроизводить на linux.

> Уж по количеству файлов реестр etc точно превзойдёт порядка на два.

В общем, какая разница? Тебя не волнует как файлы на диске хранятся? А поскольку библиотека через API доступна, то сам формат можно и поменять потом, хоть в hash-db, хоть в спец раздел...

Собственно возможен компромис. Т.е. конфигурация в реестре, но через виртуальную файловую систему он представлен и в виде набора .cfg файлов. Плюсом является то, что проще написать один раз достаточно интелектуальный парсер к одному формату, чем писать десятки парсеров для разных софтин. Собственно я почти уверен, что приходится. Скажем конфиги proftpd похожи на apache, но гарантию, что один парсер их разберёт - не дам...

> Дык, всё правильно. Сначала человек учится, а научившись спокойно работает.

Начинать на linux тяжелова-то. В 99 году мне просто пришлось осваивать linux. Да и сейчас, теже конфигурялки GNOME, KDE... Есть они, только работают по принципу - как получится, мы не виноваты. Конфиг иксов они мне уже убивали...

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

Ну это уже скорее проблема криворуких програмеров, т.е. следствие, а не причина...

> Фишка в том, что для меня (для меня _лично_) сила реестра в автоконфигурялках неинтересна

Как ни странно, для меня - тоже. Но у меня есть и знакомые, которые слишком сильно привязаны к форточкам и не решаются... У меня на самом деле есть наблюдение, что необходимость в конфигурялках и момент, когда консоль для многих функций управления становится удобнее - растянуы по времени и зависят от опыта. Т.е. в начале конфигурялки просто необходимы, что бы не страшно ;-) было, что не справишся с системой (особенно одиноким домашним юзверям). А потом уже, когда потребуется больше (и если потребуется!), то можно и ручками учится лазить...

> Но удоство работы для меня гораздо важнее world domination.

Смотря что считать удобством. Я тоже имею эгоистичные причины хотеть "world domination" - если кол-во установок на десктопы linux хотя бы приблизится к форточкам, то разработчикам мира оффтопика придётся по другому смотреть на ситуацию. Под linux начнуть переводить и поддерживать проги, типа finreader, коим до сих пор открытых аналогов нет и не предвидится... :-(

> Если знаешь, что подправить, то обычно поправить пару строк в конфиге гораздо быстрее

Не спорю, но не бывает юзеров, которые сразу знают где править. Как показывает практика с форточками начинающий разбирается раньше...

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

Нет, не полагаю. Но решения не всегда принимаются самые подходящие. Майнстрим ALSA в 2.6 - вопиёт об этом...

> Вкаком пакетном манагере наблюдаются такие проблемы?

Нет? Хм... Обычно я не сношу проги, просто сразу ставлю то, что мне надо... ;-)))

> А хрен его знает, ниразу не видел, чтобы /home глючил.

Я однажды видел как etc глючит. После каждого чека на 2 недели назад откатывался. Но там на компе винт сыпался... ;-)

> Если инфа есть,но доступа к ней нет, значит инфы нет.

Есть бабки - есть инфа. Столлман, "Право читать"... ;-)

> Нахуя апач на десктопе? Нет, ну серьёзно, зачем он там?

Я привёл его как пример не самого простого конфига. А если ребром вопрос ставить, то... например это комп веб разработчика и он сайт делает... ;-)

> На чём, если не секрет?

Delphi. В "тройном стандарте". Т.е. Разработка Delphi + MemCheck, с адаптацией для компиляции на FreePascal (win, lin...) и работой основных функций на GnuPascal.

atrus ★★★★★
()
Ответ на: комментарий от Zubok

> Как раз LR такую фишку не умеет делать. Это не активное, а пассивное хранилище. Для этогонадо демон некий придумать и придумать еще систему колбэков под это дело. То есть как сообщить прикладухе об изменениях.

FAM.

int19h ★★★★
()
Ответ на: комментарий от ugoday

> Имхо, если уж приспичило сделать единый формат конфигов, то пусть это будет скрипт-конфиг на лиспе. (термин скрипт-конфиг употреблён из-за неотличимости кода и данных). Его и руками править легко и парсилка для лиспа пишется элементарно и подходит он для всех случаев и масштабируем до жути (от убогого key=value, до всей мощи формализма рекурсивных функций).

Теперь попробуй написать гуевую конфигурялку, которая сумеет корректно обойтись с конфигом со "всей мощью рекурсивных функций"

int19h ★★★★
()
Ответ на: комментарий от ugoday

> А я не вижу причины, по которой win-реестр разростался бы. А он берёт и разростается. Сволочь глазастая.

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

> Вкаком пакетном манагере наблюдаются такие проблемы?

В любом.

int19h ★★★★
()
Ответ на: комментарий от int19h

> Теперь попробуй написать гуевую конфигурялку, которая сумеет корректно обойтись с конфигом со "всей мощью рекурсивных функций"

А что это в приципе невозможно?

Из того, что под рукой:

sawfish-ui

emacs --eval '(customize)' :)

stq
()
Ответ на: комментарий от ugoday

> Дык сейчас так и есть. Кто как хочет, тот так и хранит свои конфиги. И это правильно.

Единого API не хватает для полного счастья. Для нескольких стандартных типов, конечно.

Yampp
()
Ответ на: комментарий от atrus

>Но проблемы win реализации не обязательно воспроизводить на linux.

Если неприятность может случиться -- она случается. Если она не может произойти, она всё равно произойдёт.

>В общем, какая разница? Тебя не волнует как файлы на диске хранятся?

Как это какя разница? Я же их потом ручками курочить буду.

>Т.е. конфигурация в реестре, но через виртуальную файловую систему он

>представлен и в виде набора .cfg файлов.

Вам не кажется, что вы умножаете сущности сверх необходимого?

>Начинать на linux тяжелова-то.

Проще сразу выучиться нормально, чем сначала неправильно, а потом переучиваться. Когда я на линукс перещёл, то у меня основные проблемы были с виндузячьим сознанием. Кстати, начал я со слаки 8.0 (сейчас Current), там конфигурялок почти нет и я очень рад этому.

>Ну это уже скорее проблема криворуких програмеров, т.е. следствие, а >не причина..

Если что-то убило мою систему, то это _моя_ проблема. И если реестр позволяет одной программе нагадить во всей системе, то в топку такой реестр.

>Но у меня есть и знакомые, которые слишком сильно привязаны к >форточкам и не решаются...

Перетягивать виндузятников в GNU/Linux путём превращения его в маздай? Странный способ, даже более чем странный.

>Т.е. в начале конфигурялки просто необходимы,

Слушай историю. Был я молодым и глупым (но не безнадёжным) виндузятником. Решил попробовать Linux. Однако испугавшись сложностей побоялся ставить его сам, и попросил знакомого линуксоида поставить мне его. Тот пришёл и поставил слаку 8.0. И ушёл, ничего не объяснив, бо поздно было. Руского нет, иксов нет, звука нет, сети нет, конфигурялок почти нет. И ничего выжил, только знать больше стал.

>Как показывает практика с форточками начинающий разбирается раньше...

Это верно. Если перед _абсолютно_ новой задачей встанут виндузятник и линуксоид, то виндузятник либо справится быстрее, либо вообще не справится. Однако, если перед ними эта (или похожая) задача встанет ещё раз, то скорость будет за юниксоидом. А если это периодически возникающая задача, то тут преимущества юниксоида станет подавляющим. Т.е. виндузятник быстрее в обучении, а линуксоид -- в реальной работе.

>Но решения не всегда принимаются самые подходящие.

? Вы всерьёз так думаете?

>Но там на компе винт сыпался... ;-)

Против лома нет приёма.

>Есть бабки - есть инфа.

Лучше так. Есть инфа.

>это комп веб разработчика и он сайт делает.

Если веб разработчик не может прочесть конфиг апача, то это не веб разработчик, и не сайт он сделает,а ....

Что я апач не настраивал что ли? У него конфиг самодокументируемый. Вообще образцовый конфиг. Если ничего особо серьёзного не надо, то человек впервые видящий апач может настроить его по комментариям.

>Delphi.

Не люблю я его. Он мне всю жизнь поломал. ;(

2int19h

>Теперь попробуй написать гуевую конфигурялку, которая сумеет >корректно обойтись с конфигом со "всей мощью рекурсивных функций"

У нас GNU/Linux или где? Я буду писать гуй, а с лямбда-исчислением будет разбираться CommonLisp, или какой другой транслятор.

>В любом.

Ниразу не сталкивался.

ugoday ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.