Реестр! Ы!

файл я могу найти СТАНДАРТНОЙ утилитой поиска. А как искать ключи в вашем реестре?

Стандартной утилитой поиска в реестре. То, что ты написал слово капсом не делает его ужасающим аргументом.

Причём проиндексируете по параметру.И поиск будет по параметру. А как искать по значению?! Не нужно?

Продолжай спорить с собой, я понаблюдаю.

Стандартной утилитой поиска в реестре

Кастую стандартный sed реестра, стандартный diff реестра, стандартный patch реестра, стандартную VCS реестра etc.

Если для xml формата , то diff реестра, стандартный patch :

http://diffxml.sourceforge.net/

а sed и нафиг не нужен при разнообразии dom и xslt примочках.
И вообще, весь тред сплошная феерическая стена плача незнаек web-технологий.))

Не понимаю, почему темы об унификации доступа к конфигурационным данным всегда скатываются к реестру. Но. Тем не менее. Есть стандартная утилита regedit, которая экспортирует и импортирует реестр в ini' подобный файл. Внезапно. С которым ты можешь это всё проделывать твоими «стандартными» штуками. Где у /etc/ стандартные точки восстановления кстати, а? )

Где у /etc/ стандартные точки восстановления кстати, а?

/opt/backup, естественно. Зовутся очень понятно, кстати - etc_2010-12-19.tar.bz2, etc_2010-12-20.tar.bz2, etc_2010-12-21.tar.bz2 и так далее. Или вас с этим попоболь возникла???

Что непонятного в слове «стандартные»? :]

avatar@AliSo ~ % ls -l /opt/backup
ls: невозможно получить доступ к /opt/backup: Нет такого файла или каталога

oh shi~~

>Стандартной утилитой поиска в реестре. То, что ты написал слово капсом не делает его ужасающим аргументом.

я вот про что вам говорю: предположим, вы сделаете реестр. Ок. И засунете туда утилиту поиска. Ты что, хочешь сказать, что вам удастся создать Тьюринг-полный ЯП для вашей утилитки поиска? Который развивается >30 лет?! Который имеет альтернативы? Не верю. Будет у тебя там тупой find как в regedit'е. А у меня есть sed & awk. Вот только, очень неудобно парсить sed'ом BLOB'ы. Поверь мне. А необходимость sed'ить конфиги - бывает.

Вспомни автостарт в Windows - существует свыше 30 разных мест по всему реестру, где можно стартануть какой-нить вирусняк/кейлоггер/вписать гадость по вкусу. И фиг найдёшь... В отличие от скажем Slackware Linux, которая аккуратно содержит стартовые скрипты в строго отведённых местах. На практике, найти автостарт в Slackware в разы проще чем в Windows. Хотя кажется, что наоборот. Особенно удобно искать информацию в конфигах, которые создаёт сама ОС, например - как узнать какое ПО когда установлено в систему? и какие конкретно файлы? В бинарных дистрах с rpm & dpkg ты устанешь мучать гугл/ман на эту тему. В Slackware для этого достаточно стандартных утилит из codeutils (ls, less, любимый редактор, sed, grep)

Продолжай спорить с собой, я понаблюдаю.

у тебя есть другие предложения? ты собираешься включить в БД индекс по полю «значение»? Знаешь, как на практике приходится править БД? Очень просто: делаем дамп, прогоняем через sed, и заливаем обратно. Всё потому, что встроенных средств самой БД часто недостаточно. Но это тогда, когда БД необходима. И то, всё плохо - смотри, изменилась одна ячейка БД, но для обработки/бекапа тебе приходится сливать сотни метров (а то и больше!) дампа. Да, и VCS не привинчивается к БД - потому как не тексмтовая это БД (даже если там текстовые данные).

Да, и ещё: для эффектного управления твоей гипотетической ОС с реестром мне нужно скурить over9000 манов, и выучить специализированный ЯП (который ты туда впихнёшь). Для управления slackware, где всё на текстовых конфигах и bash-скриптах мне не нужно ничего учить: я и так УЖЕ всё знаю. sed ты не привинтишь к своему реестру, придётся тебе либо городить своё, либо оставить только самый примитив как в венде. Вердикт - фтопку. Хотя идея да, красивая. Только не нужная. Реестр целесообразен лишь на десктопе с Win95, где 10 установленных программ. Для чего-то более функционального реестр слишком не масштабируем. А для чего-то более мелкого (роутер например) реестр избыточен.

> Для управления slackware, где всё на текстовых конфигах

О, это ключевой момент для понимания писанины этого луддита ))

>Где у /etc/ стандартные точки восстановления кстати, а? )

man tar

Какой то бред.

я вот про что вам говорю: предположим, вы сделаете реестр. Ок. И засунете туда утилиту поиска. Ты что, хочешь сказать, что вам удастся создать Тьюринг-полный ЯП для вашей утилитки поиска? Который развивается >30 лет

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

Вспомни автостарт в Windows - существует свыше 30 разных мест по всему реестру, где можно стартануть какой-нить вирусняк/кейлоггер/вписать гадость по вкусу. И фиг найдёшь...

В ляликсе одно ядро стартует как минимум два процесса - hotplug и init. По факту есть еще слушающие netlink умники. Ты в конфигурационном дерьме этих вот вещей давно бывал? Вспомнишь сходу куда надо смотреть что бы найти всё, что запускается? ) Про то что стартует йузерспейсное говно можно просто молчать. Всё на скриптах

Да, и ещё: для эффектного управления твоей гипотетической ОС с реестром мне нужно скурить over9000 манов, и выучить специализированный ЯП (который ты туда впихнёшь).

ГАГАГАГА

no comments

Какое слово тебе не понятно в «стандартные точки восстановления»? ))

Итак, ты создал «стандартную точку восстановления» и изменил 18 параметров у 4 программ. Теперь откати из своей «стандартной точки восстановления» 2 параметра для одной программы. А также, например, определи чем отличияются настройки 5-й программы на двух соседних компьютерах. Как научишься делать это - возвращайся, будешь обьяснять очередному идеологу насколько текстовый читабельной конфиг лучге блоба.

regedit -> export сделает тебе «текстовый читабельный конфиг»

>Попробуй придумать зачем это нужно в унифицированном хранилище.

sed'ить БД? ну а как я поменяю скажем все eth0 на eth1? ручками? как в венде?

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

потому-что написать однострок на sed дело 5и минут. написать парсер на скажем php - дольше. Да и не факт, что у нас есть этот php. А как чужие скрипты запускать? Например я нагуглил однострок на ruby, которого не знаю, где гарантия, что он не сделает rm -rf ? sed есть везде, в ЛЮБЫХ системах.

Потом попробуй придумать что будет, если хранилище будет находится на локальном узле только частично.

не вижу проблемы. вам запрещено обрабатывать удалённые файлы? мне проще набрать ssh sed... Чем ломать себе голову, как подключить по этому-же ssh ваш regedit.

Ты уже научился восстанавливать из «стандартной точки восстановления» только требуемые изменения? Нет? Тогда брысь отсюда

>Какое слово тебе не понятно в «стандартные точки восстановления»? ))

мне все слова понятны. смысл фразы не ясен. это-же что-то вендовое? В Linux'е сделать «точку восстановления» очень просто: пишем cp programm.conf programm.conf.old и - ВСЁ. Можно всю /etc забекапить. Можно делать это по расписанию. Как это сделать с реестром - решительно непонятно (разве что dd весь хард. что и практикуют маздайщики). Будете наворачивать туда свой планировщик+архиватор? Вы мне ещё ЯП Тьюринг-полный не сделали. ;)

Что тебе не понятно в словосочетании «точка восстановления»? Ради интереса, как ты восстанавливаешь только требуемые значения из своей «стандартной» /opt/backup/*.tar* ?

Кстати, раз уж такие придирочки. Расскажи мне, как на произвольные элементы конфигурационных файлов ставить различные права доступа.

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

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

cat /etc/httpd/conf/httpd.conf | grep include
ls -l /etc/httpd/conf.d/*.conf
ls -ld /etc/sysconfig/*

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

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

проблемы у пользователей реестра.

Я хочу, что бы у меня поле description базы passwd имел доступ только юзер vasya. Вперед.

Им действительно неоткуда взяться, потому что всё свалено в одну помойку. Это верно

> Кастую стандартный sed реестра, стандартный diff реестра, стандартный patch реестра, стандартную VCS реестра etc.

для универсального реестра всё это необходимо будет написать. и vcs тоже, да.

>для универсального реестра всё это необходимо будет написать. и vcs тоже, да.

стандартный cron реестра, стандартный ls реестра, стандартный DVCS реестра, стандартный... Это сколько-же метров займёт?! А сколько памяти пожрёт? (как я понимаю, база с обвязкой должна постоянно висеть в памяти?)

Может семёрочку правильнее и проще?

Я хочу, что бы у меня поле description базы passwd имел доступ только юзер vasya

Для редактирования атрибутов учетных записей предназначены утилиты passwd, usermod, chfn и другие. Потому, что юзера vasya в /etc/passwd нет, а он есть например в /var/lib/mysql/userdb/users.

> Может семёрочку правильнее и проще?

если чо, MS уже сколько лет мечтает вместо файловой системы использовать базу данных. Хотели впилить в висту, да ниасилили. В десяточке точно будет )

>Ты что, хочешь сказать, что вам удастся создать Тьюринг-полный ЯП для вашей утилитки поиска? Который развивается >30 лет?! Который имеет альтернативы? Не верю. Будет у тебя там тупой find как в regedit'е. А у меня есть sed & awk.

sed & awk тьюринг полные? Какие извращения, оказывается, существуют в мире линукс…

>если чо, MS уже сколько лет мечтает вместо файловой системы использовать базу данных. Хотели впилить в висту, да ниасилили. В десяточке точно будет )

файловая система == БД. так, между прочим...

Они вроде используют перловые регэкспы а перловые регэкспы - тьюринг-полные

etcfs же!

Хм…

>sed & awk тьюринг полные? Какие извращения, оказывается, существуют в мире линукс…

почему извращения? про awk точно не помню, но sed тюринг полный ЯП. кстати, ещё и компилируемый (опционально). я часто пишу достаточно сложные sed скрипты, в десятки, а то и сотни строк. кроме того, иногда одни sed скрипты создают и запускают другие. Преимущество - высокая скорость написания «одноразового» скрипта.

>я часто пишу достаточно сложные sed скрипты, в десятки, а то и сотни строк

Вот такие понапишут, а потом это добро лежит мёртвым грузом, т.к. никто не понял что оно делает… :}

Ты не поверишь но многие версии SQL тоже тьюринг-полные.

>SQL

Это вообще лучше закопать. С таким синтаксисом это ж удавиться можно.

> файловая система == БД. так, между прочим...

реляционную. так чтобы понятия «файл» вообще не было, было бы понятие «ресурс» которое можно получать запросами.

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

>Вот такие понапишут, а потом это добро лежит мёртвым грузом, т.к. никто не понял что оно делает… :}

меня это слабо волнует. я для повседневных задач пишу. очень долго создавать одноразовое С++ приложение.

Да?! Елки палки, что же делать. А как же моя «стандартная» точка восстановления в /opt/backup? А как же diff? А как же svn?

Давай я тебе объясню принципиальную причину, по которой ты не можешь выйти из этого спора победителем.

Тут простая штука: для формализованного хранилища или протокола доступа к хранилищу я всегда смогу построить такой формат файла, для которого будет существовать изоморфное отображение _всех_ доступных через API данных и обратно, тем самым сведя проблему к существующей. А ты для разнобойного дерьма из /etc этого сделать не сможешь.

// З.Ы. Для особо непонятливых - я не поклонник реестра, а сторонник унифицированного API для доступа к данным конфигурации. Впрочем, даже с реестром не всё так плохо, как с помойкой в /etc, ~/. , ~/.config/

> А ты для разнобойного дерьма из /etc этого сделать не сможешь.

Почему это не сможет? Augeas же.

>А ты для разнобойного дерьма из /etc этого сделать не сможешь.

Ну вон в сусях, дебианоподобных и в том же альте, например, пытаются.

Я на работе сузей пользуюсь. Давай не будем об этом вспоминать. Это такая попоболь >_<

Строят город на болоте. Но будем за них болеть :D

> Строят город на болоте.

Ну уж точно не более безнадежно, чем твое «изоморфное хранилище» :)

Но будем за них болеть :D

Будем.

а sed и нафиг не нужен при разнообразии dom и xslt примочках.

Представленный выше конфиг предлагалось хранить в виде строки или бинарного блоба. И чем мне твои dom и xslt в данном случае помогут?

Не понимаю, почему темы об унификации доступа к конфигурационным данным всегда скатываются к реестру.

Потому, что реестр есть и (хоть как-то) работает. В отличии от твоих фантазий.

Есть стандартная утилита regedit, которая экспортирует и импортирует реестр в ini' подобный файл Внезапно. С которым ты можешь это всё проделывать твоими «стандартными» штуками.

т.е. предлагается экспортировать реестр в ini-файл, обрабатывать его text-utils, затем импортировать обратно?

Где у /etc/ стандартные точки восстановления кстати, а? )

man VCS

Неверные предположения порождают неверные вопросы ?)

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

Я ее и сам знаю, и эта причина формулируется просто: я (no-dashi) не спорю с идиотами и троллями. Поэтому отправляйся дальше откатывать изменения одной программы из пяти из «единой точки восстановления».