/etc-xml

61 сообщение / 0 new

Для комментирования войдите или зарегистрируйтесь

Последнее сообщение

пт, 24/03/2006 - 18:25

RNZ

Не в сети

Зарегистрирован: 24/09/2010

/etc-xml

всё ниже этой строки можно пропустить и обсуждение продолжить с http://www.nclug.ru/forum_viewtopic.php?8.7718.0#11540

Сия ветка выливается из обсуждения в ветке http://www.nclug.ru/forum_viewtopic.php?9.6951.17

Не отсносящееся те теме:
[b]Ne01eX, Nick[/b]
У моего провайдера не ADSL. Используется оптоволоконное кольцо по городу, на которое по натыканы узлы с переходом с SFP на LAN (D-link DES-3326SR), до некоторых клиентов, находящихся далековато от узлов, как в моём случае, используется VDSL подключение, скорость 4 Мбит/сек, абонетскую плату не плачу - оплатил тока раз за подключение, траблы начались после того как провайдер перевёл свои коммутаторы DES-3326SR на RIP. Я свою траблу решил. Мой текущий дистрибутив Fedora Core 4. Ну а настройку pptp я привёл как пример не оптимальности обычного конфигурирования, а не как рассказ о половой жизни.

Что касается RT - так уж получилось, что мне пришлось иметь опыт работы/программирования со всякими QNX, RTLinux, LinuxSRT. Продолжать эту тему не будем. Скорее это я неудачно привёл пример. Но в любом случае любой прирост производительности - есть благо, а сколько комп простаивает это уже личное дело каждого[b].[/b]

Теперь что касается темы:
[b]Ne01eX[/b]
[i]"Однако, вы уже не в первом посте блистали глубокими познаниями в XML и не в первом посте аргументированно доказывали его эффективность. Что-ж дерзайте. Переведите хоть что-нибудь из ПО используещее каталог /etc с plain text на XML и если это зачинание будет позитивным (иметь видимое приемущество перед plain text), то я уверен, что Linux-сообщество вам поможет."[/i]
Ne01eX, познаниями в XML я не блещу, скорее просто вижу его достоинства.
преведённый кусочки кода, являются переделанными кусочками уже существующих xml-конфигов от Gnome, приведу эти кусочки в этой ветке:
Конфиг, подобный ниже указанному позволил бы сразу однозначно определять тип переменной в конфигурации:
<div class='indent'>...
<pref name='core'>
<pref name='network'>
<pref name='auto_ip' type='bool' value='0' />
<pref name='public_ip' type='string' value='192.168.100.100' />
...</div>

Можно генерить доку/хинты прямо по конфигурации:
<div class='indent'>...
<pref name='core'>
<pref name='network'>
<pref name='auto_ip' type='bool' value='0'>
<local_schema locale="en" short_desc="Automatic IP configuration">
<longdesc>"Bla-bla-bla..."</longdesc>
</local_schema>
<local_schema locale="ru" short_desc="Avtomaticheski konfigurim IP nax!">
<longdesc>"Bla-bla-bla..."</longdesc>
</local_schema>
</pref>
<pref name='public_ip' type='string' value='192.168.100.100' />
...</div>

[i]"Более того, я вам обещаю как координатор RTK Linux сопровождение вашего форка в составе дистрибутива."[/i]
Если всё же начну разработку сам, то ловлю на слове!

[i]"А вот предложив программисту выбирать, что использовать для сохранения настроек вы сморозили глупость. Подумайте и сами себе ответьте почему =)."[/i]
На это отвечу следующее - Думаю Вы знакомы с термином "Deprecated", так вот позволить придётся так или иначе, потому как если вдруг моё предложение найдёт поддержку у Linux сообщества, то переход будет происходить не единовременно, а постепенно. И даже в случае очень успешного продвижения xml aля regAPI, думаю ещё очень долго будут существовать/появляться приложения использующие обычный подход (который возможно объявят "Deprecated").

[b]Sheridan[/b]
[i]"1. А нафига нам нужен overhead xml'ный?
2. Править вручную - неудобно
3. Формат не предназначен для визуального просмотра"[/i]1
Ну можно и не создавать etc-xml, а сделать /etc/etc-xml, но я бы предпочёл вариант /etc-xml, потому как нагляднее, кроме того я бы запретил ручную правку как таковую, доступ на запись/чтение через - regAPI, консольной тулзой или gui-шной, для чтения можно применять xslt представленяи, для консольного просмотра можно, использовать упрощённое представление.

[i]"xml имеет смысл применять когда действительно нужен многомерный конфиг. Например описание интерфейса окна. А для остального набного более удобен обычный 2мерный ini формат или одномерный key=value
Короче. Не пытайся везде прикручивать сложности. Там где можно без сложностей, пускай будет просто. xml это тяжелый формат, и не надо его прикручивать там где без него можно обойтись. А в ядре оно и подавно не нужно :)))
Не умножай сущности."[/i]
Сказанное Вами не есть аргумент. XML - не "тяжелый формат", а строгая иерархия. Нужно оно в ядре или не нужно, сейчас особо не актуально, но как возможность исключать нельзя.

[b]igorsia[/b]
[i]"а зачем держать две системы конфигов? не проще ли отображать конфиг из xml в псевдофайловую систему etcfs сделанную на подобе sysfs и procfs"[/i]
Думаю такой подход был бы не слишком оптимален. sysfs, procfs - являются адаптацией к представлению в файловой структуре не файловых данных. А xml-файлы - это файлы, так пусть хранятся там где им и положенно - в директории на файловой системе.

Развивая идею:
Можно например добавить такой функционал как версионность, т. е.
Изменяя значение пользуя XMLRegAPI (условно назову его так), текущий xml-файл переименовывается (добавляется постфикс _даты_времени последней модификации/создания файла) и пишется его новая версия, ну естественно добавить ограничение на кол-во версий, всмысле удалять старые конфигурации, думаю этого будет вполне достаточно и в сложных системах типа SVN нет нужды.

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

[ Редактирование ]

пт, 24/03/2006 - 21:38

igorsia (не проверено)

2nick Влияет в основном местоположение... например конфиги Bind лежат частично,
а именно описания зон в /var/named.
Кроме того меня раздражает, что некоторые дистрибутивы начали создавать
подобные системы, на свой лад причем подобная ситуация сложилась, например с ястом, когда конфиги в etc создаются из его
конфигурилки, а данные для нее хранятся отдельно, судя по тому, что ручная правка
конфигов не дает нужного результата.
Безусловно, хранить настройки для унифицированного конфигуратора проще в унифицированном файле, и нужны они будут один раз - при запуске.
а вот делать это все в xml формате при создании etc-fs абсолютно не нужно - не кто не хотят заморачиваться работают с etc-fs. Конфигуратору типа Yast и более продвинутым проектам проще рабоать с бинарным форматом, рассчитаным на представление данных в виде дерева.
[ Редактирование 24.03.2006 - 20:40:25 ]

пт, 24/03/2006 - 21:39

igorsia (не проверено)

[ Редактирование 24.03.2006 - 20:39:46 ]

сб, 25/03/2006 - 00:35

Sheridan

Не в сети

Зарегистрирован: 20/09/2010

[quote=RNZ]Я реально думаю заняться на досуге проработкой идеи, так что критика и предложения только приветствуются.[/quote]
Да ненужно никому это будет...
Как ты собираешся апача настраивать чтобы он юзал твои конфиги? А апитаблы?

сб, 25/03/2006 - 02:59

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]Sheridan[/b]
Да нафига мне пытаться переделывать апач!?
Я предлагаю разработать систему которая бы более отвечала требованиям современности, позволила бы поставить в более жесткие рамки программистов, придала бы унификацию и при этом предоставила достаточный функционал для реализации своих идей. И оглядываясь на Windows Registry, хотелось учитывать все те недостатки которые присущи ей, и уже давно.
А уж переносить на /etc-xml свой софт или нет, пусть программист решает сам.
[ Редактирование 25.03.2006 - 23:13:27 ]

сб, 25/03/2006 - 16:12

Nick

Не в сети

Зарегистрирован: 20/09/2010

RNZ:
Ну раз уж вы все-таки твердо решили изобретать велосипед с квадратными колесами, то вот вам проект таких же изобретателей:
http://www.libelektra.org/

Присоединяйтесь к ним. А то опять получится 15 проектов с одинаково слабой функциональностью вместо одного с нормальной. Кстати, они это сделали в userspace, а не в ядре, и это очень правильно. Или вы скажете, что настоящие пацаны пишут только в kernel level?

вс, 26/03/2006 - 01:58

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]Nick[/b]
Спасибо за линк, ознакомился, посмотрел презентацию, увидел несколько интересных идей, но всё же присоединяться к этому проекту не стану. Я не согласен с некоторыми идеями которые реализовывают разработчики libelektra и мною проглядываются явные недостатки предлагаемой системы:
1) Есть поговорка - "за двумя зайцами погонишься ни одного не поймаешь" и есть контр-поговорка "убить двух зайцев стразу", так вот подтвержение второй поговорки встречается гораздо реже и зачастую эти успешные случаи подтвержения относятся к значительно менее замашистым проектам чем libelektra. Разработчики же libelektra пытаются одим махом охватить все что уже было создано и причём для разных осей! Чем это чревато, не трудно предугадать.
2) Не сомненен так же факт того, что при смене курса какими либо разработчиками приложений настройку которых обеспечивает libelektra, автоматически выплывает наружу "legacy" направленность проекта, то бишь его автоматическая подверженность устареванию, иными словами если httpd например станет хранить свои конфиги в новом структурном формате, о котором libelektra ничего не знает, потребуется что-то типа нового слоя для обработки этих конфигов, тут идёт намёк на плагинабельность. Не думаю, что такой подход удобен и правилен. Система конфигурирования должна носить унифицированный характер, а не походить на программу 1С-Предприятие.
3) Наблюдается отсутствие полноценного контроля значений на соотвествие типу, так же как при использовании ручного редактирования plain text'a.
4) Встречаются вещи со слабо проработанными идеями, например, к следующей строке - "system/net/ISP/.MSN/login" - в презентации даётся такой комментарий - "This little dot makes inactive the entire “MSN/*” subtree" - какой же логикой руководствуются люди реализующие такое? Может я слишком внимателен к мелочам, но на мой взгляд, такая реализация, отключения элемента вписыванием точки в начале его названия, является не нужной ахинеей.
5) В презентации, постоянно приводится агрументы - пользуется plain text (типа можно в случае если что-то пошло не так в ручную исправить - "If everything else fails, you can still directly edit the key database with vi, because it is all plain text !"), отсутствие демона, нет сетевого интерфейса для управления.
Я лично предпочитаю что бы, система конфигурирования содержала определённый функционал в плане усточивости к сбоям. Т.е. например, в системе не мешало бы присутствие флага успешности загрузки системы после смены настроек, и если этот флаг установлен в отрицательное положение, то грузить последний успешный набор конфигурационных файлов, так же можно было бы добавить возможность подгрузки конфигурации из backup'а или внешнего источника (USB-флешки например). А сетевой бы интерфейс не помешал бы для удалённой правки и мониторинга, его то как раз можно было бы, по аналогии с Windows сервисом "Remote Registry", реализовать в виде демона для доступа XMLRegAPI.

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

Что касается левелов kernel/userspace, я уже не раз высказался по этому поводу, но ещё раз повторюсь:
в ядро интегрировать xml-парсер не обязательно, единственное для чего он может грузиться в ядре - читать конфигурацию для ядра из xml, необходимость в этом крайне мала, но для аргумента достаточно присутствия возможного полного ухода от хранения каких либо конфигураций в plain text, в том числе и конфигураций ядра.

[ Редактирование 26.03.2006 - 01:13:01 ]

вс, 26/03/2006 - 20:28

edge (не проверено)

Твои бы старания, да богу в уши бы..
Я завсегда за труд. Ненавижу советчиков, первонахов, и уродов, сбивающих с нужного пути. Если считаешь, что твое дело нужное, то заверши его до конца. Если нужна помощь, - обратись ко мне, трафик мой, идеи - твои. Помогу. Мне ничего не надо, только результат под GPL.
wbr, Edge

---
Блин, чем-то на спам похоже.. ;-)

[ Редактирование 26.03.2006 - 20:33:23 ]

Пнд, 27/03/2006 - 07:46

Ne01eX

Не в сети

Зарегистрирован: 20/09/2010

[i]>>>преведённый кусочки кода, являются переделанными кусочками уже существующих xml-конфигов от Gnome, приведу эти кусочки в этой ветке:[/i]

Да правил я, матерился. Еще более недоумевал над fontconfig и его xml'овским local.conf, который по сути повторяет xorg.conf в секции про фонты.

[i]>>>Ну можно и не создавать etc-xml, а сделать /etc/etc-xml, но я бы предпочёл вариант /etc-xml, потому как нагляднее,[/i]

Зря распинаетесь. и /etc и /usr/etc и /usr/X11/etc есть ничто иное как $prefix/etc. Если вы заботитесь о универсальности, то должны позаботиться о переносимости вашего мегареестра (ну извините, обозвал), куда пожелает пользователь (в данном случае пользователем явлается разработчик/майнтейнер). Теперь об откровении: одна из причин до сих пор достающая меня в Slackware Linux, - это неправильное, на мой взгляд расположение файлов. Ну не понимает моя тупая голова, за каким х.. иксовый софт расположен, скажем, не в /usr/X11/(s)bin, а в /usr/(s)bin, а конфиги держит в /etc. С другой стороны если, конфиги будут разбросаны по всей файловой системе, то потеряется определенный смысл в разработке. Ну не понимает эта же голова, зачем держать часть документации в $prefix/share/doc, тогда как есть для этого отдельный каталог -> $prefix/doc. Как вариант - /var/etc-xml и ограниченная свобода программисту.

[i]>>>кроме того я бы запретил ручную правку как таковую, доступ на запись/чтение через - regAPI, консольной тулзой или gui-шной, для чтения можно применять xslt представленяи, для консольного просмотра можно, использовать упрощённое представление.[/i]

Отдельная утилита это хорошо, однако...
[url=http://nclug.ru]тут[/url] 99% пользователей сидя в KDE предпочитают работать в mc. Так что, пока к mcedit не разработаете соответсвующий режим, не видать вам лавров революционера ;)

[i]>>>Если всё же начну разработку сам, то ловлю на слове![/i]

Заметано.

Да, сложной и очень тонкой темы вы коснулись... Многими она будет непринята сразу, или же непринята совсем, однако все-таки хочется надеется, что все будет пучком. Ну, либо вы признаете несостоятельность своей идеи ;)
[ Редактирование 27.03.2006 - 07:48:44 ]

Пнд, 27/03/2006 - 15:48

#10

Zmey (не проверено)

2RNZ:
Такой вопрос.
Ты в /etc-xml хочешь хранить один большой XML-файл для ВСЕХ настроек, или по старинке - каждой программе свой config-файл в формате XML?

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

2. Нет, каждый конфиг-файл будет храниться отдельно. В таком случае не вижу никаких преимуществ в переводе программ на XML-конфиги, кроме смены формата (текст->XML).
Унификация? Фигня. Если я кину клич "а давайте переведем все конфиги в формат виндовых INI-файлов и будем пользовать API а-ля виндовый GetProfileString()" - у моей идеи будет ровно столько же преимуществ, сколько и у твоей. Зато огромный минус XML - это то, что хрен ты в нём сможешь закомментировать параметр, придётся удалять совсем. И как вообще комментарии размещать в XML-конфигфайле? Спецательным тегом отмечать?
Более строгая проверка типов? Тоже фигня. Что делать, если ты затребуешь параметр, скажем, типа boolean, а в конфиге он фигуряет как имеющий тип integer? А? С ошибкой вываливаться будем? Или как в винде - вернем INTEGER и в специально отведенное место запишем, что тип данных был XMLREG_INTEGER, а не XMLREG_BOOLEAN? Дык 99% программ положат на проверку типа данных длинный и волосатый... хмм... локоть.
Ручную модификацию уберем, и это есть хорошо? Фиглитам.
Во-первых, ежели обязать каждого разработчика привинчивать к своему творению "свою" приблуду для конфигуряния, фиг ты чего добьёшься. Ладно графические программы - у них окошко с настройками как бы уже стандарт. А демоны? Что, к каждому superdaemond заставлять писать superdaemond-configurator? Куда-куда проследовать? :)
Вывод: придётся разработать универсальную приблуду для изменения XML-конфигфайлов независимо от того, для какой программы он предназначен. И что мы поимеем в результате? Всё тот же геморрой с ручной правкой конфигов, только теперь уже не в текстовом редакторе, а в суперприблуде xml-regedit. И вместо простых и понятных текстовичков, в которых легко можно закомментировать всё, что угодно, и вообще разместить сагу "о правильном и здоровом редактировании", получим нечто невразумительное, "зато единообразное".

Пнд, 27/03/2006 - 17:46

#11

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]edge[/b]
Спасибо, за поддержку, как только идеи, мысли и рассуждения начнут выливаться в код, сразу подумаю над разделением труда. И всё будет исключительно под GPL.

[b]Zmey[/b]
Каждой программе свой config-файл в формате XML можно ещё и подкаталог, в виде узла с изоляцией, с набором конфиг файлов, точнее даже предпочтительнее.

Индексировать XML файл - можно, можешь посмотреть примеры работы с ClientDataSet в Delphi/Kylix на базе MIDAS.

Далее отвечу не попорядку (ответы перекликаются):

Рисовать " "свою" приблуду для конфигуряния" совсем необязательно, можно пользовать подход Export/Import как с *.reg или *.sql файлами.

Насчёт проверки типов - именно такого подхода и необходимо избежать, а значит надо предопределить стандартные типы.
Тоже касается и отключения параметров - да именно тегом, и для комментирования тоже тег, всё тегами - так как соблюдается иерархическая структура!
Хотя конструкции <div class='indent'></div> тоже не собираюсь отменять, только вот подойдёт она лишь для ручного редактирования файлов предназначеных для Import'a!

Насчёт "Ручную модификацию уберем" и вывода - в целом всё правильно, кроме принципиального упущения из виду одной детали - конфиг который будет импортироваться в xml-реестр, будет подвергнут валидации, а значит принципиально можно избежать львинной доли, возникающих при не правильном ручном редактировании, проблем. А именно - отчасти защититься от криворукости. Следствием этого, возможно станет, значительно увеличившееся кол-во пользователей/программистов на Linux - думаю к этому собственно все кто "поселился" на этом форуме и стремятся.

[b]Ne01eX[/b]
"/var/etc-xml" - насчёт рассположения стоит ещё подумать, разграничение между индивидуальными пользовательскими настройками и настройками системы само собой необходимо, в любом случае чему-то вроде - /home/%user%/etc-xml - быть.

mcedit, vi, и др. - "посвящается" Export/Import (будем надеяться что Microsoft не додумается получить на Export/Import - патент 8) ).

Не состоятельность идеи я навряд-ли признаю, а вот признать свою не состоятельность, как программиста способного реализовать данную идею в полном объёме, пару процентов есть 8) .
[ Редактирование 27.03.2006 - 17:57:12 ]

Втр, 28/03/2006 - 07:57

#12

Sheridan

Не в сети

Зарегистрирован: 20/09/2010

RNZ возьмись лучше за более насущные проблемы. XML не стоит заморочек.
К примеру универсальный менеджер пакетов который бы понимал существующие форматы...
Вот тебе для затравки:
Объектная модель:
http://sheridan.stavcom.ru/filez/object_model.png

Добавление пакета:
http://sheridan.stavcom.ru/filez/add_package.png

Установка пакета. Тут просто:
http://sheridan.stavcom.ru/filez/install_package.png

БД менеджера
http://sheridan.stavcom.ru/filez/database.png

[color=red]Блин, Sheridan, всё круто, публика в экстазе, но в следующий раз такие широкие картинки давай ссылками - страницу рвёт.
Zmey[/color]
[ Редактирование 28.03.2006 - 11:51:47 ]

Втр, 28/03/2006 - 11:37

#13

Zmey (не проверено)

[quote=RNZ]Каждой программе свой config-файл в формате XML можно ещё и подкаталог, в виде узла с изоляцией, с набором конфиг файлов, точнее даже предпочтительнее.[/quote]
Это будет точно такой же бардак, как и сейчас в /etc, только с официально подведенной теоретической основой. :)

[quote=RNZ]Индексировать XML файл - можно, можешь посмотреть примеры работы с ClientDataSet в Delphi/Kylix на базе MIDAS.[/quote]
Не могу - кайликса нет и не будет в ближайшее время. Впрочем, как там делается индексация, я примерно представляю - небось оффсеты в файл хранятся? Дык XML это вам не REG, там если один символ в каком-либо поле уберется - придётся перестраивать весь индекс (т.е. имеем быстрый поиск в файле за счёт гипер-тормознутости при внесении изменений).

[quote=RNZ]Рисовать " "свою" приблуду для конфигуряния" совсем необязательно, можно пользовать подход Export/Import как с *.reg или *.sql файлами.[/quote]
И как ты себе это представляешь? "Пасаны, для того, чтобы изменить параметр, правьте сначала во-он тот текстовичок, а потом импортируйте его в реестр". А текстовичок в каком формате, кстати, будем делать? Как виндовый .REG-файл - а-ля INIшка? %-6

[quote=RNZ]Насчёт проверки типов - именно такого подхода и необходимо избежать, а значит надо предопределить стандартные типы.
Тоже касается и отключения параметров - да именно тегом, и для комментирования тоже тег, всё тегами - так как соблюдается иерархическая структура!
Хотя конструкции

< !-- BLA-BLA-BLA -- >

тоже не собираюсь отменять, только вот подойдёт она лишь для ручного редактирования файлов предназначеных для Import'a![/quote]
Аха, значит, импортировать файлы будем в формате XML? Тогда могу предложить скрипт для скоростного импорта файла в реестр:
[b]cp твой_файл /etc-xml/[/b] B-)

[quote=RNZ]Насчёт "Ручную модификацию уберем" и вывода - в целом всё правильно, кроме принципиального упущения из виду одной детали - конфиг который будет импортироваться в xml-реестр, будет подвергнут валидации, [/quote]
стоп-стоп-стоп. И каким образом ты собрался валидировать конфиги, не зная, какие именно параметры используются той или иной программой? Вот стоит в конфиге параметр "EmailOfVasyaPupkin" типа BOOLEAN - откуда ты знаешь, правильно ли его тип указан или нет? Может, там строка должна быть? :)
Проверить ты сможешь только самое-самое примитивное: соответствие формату XML и соответствие данных типу (например, если BOOLEAN - то строка "куку" отпадает, т.к. она не true/false). И на этом - ВСЁ. Ради такой вот убогой валидации городить огород с XML и перепиливанием всей системы (всей-всей!) под новый "реестр"? Данунафик...

[quote=RNZ]а значит принципиально можно избежать львинной доли, возникающих при не правильном ручном редактировании, проблем. А именно - отчасти защититься от криворукости.[/quote]
Не пойму я - ты вроде не вьюноша бледный со взором горящим, а такие наивные речи ведешь... От криворукости защитит только одно - линейкой по рукам, да почаще... А отдельным особям и в табло полезно засветить, ибо по-другому они не понимают.
[b]Принципиально[/b] ты никак не сможешь защититься от криворукого юзера. Просто потому, что он легко сменит тип данных в конфиге, и твоя программа вместо boolean в 1 байт получит в буфер строку текста полметра длиной - с соответствующими последствиями.

[quote=RNZ]Следствием этого, возможно станет, значительно увеличившееся кол-во пользователей/программистов на Linux - думаю к этому собственно все кто "поселился" на этом форуме и стремятся.[/quote]
Следствием этого будут выросшие на пустом месте грабли, об которые программистам и пользователям придётся регулярно спотыкаться. В результате значительно увеличится трафик usenetовских эх типа linux.suxx.

[quote=RNZ]Не состоятельность идеи я навряд-ли признаю[/quote]
Да уж признай пожалуйста. :-)

2Sheridan:
Выложенная тобой принципиальная схема нового крутого велосипеда с квадратными колёсами вызывает неподдельное восхищение и заодно рвёт страницу в браузере. Сам уберёшь или мне помочь? :-)
PS: Уже помог. B-)
[ Редактирование 28.03.2006 - 11:55:36 ]

ср, 29/03/2006 - 08:07

#14

Sheridan

Не в сети

Зарегистрирован: 20/09/2010

Что поделать, все мы велосипедисты...

ср, 20/09/2006 - 01:04

#15

RNZ

Не в сети

Зарегистрирован: 24/09/2010

По анализировал, по ковырял, по думал - признал не состоятельность идеи. 8) Однако идею заценила microsoft 8) - похожее реализуется в vista'е. Но это так флюиды.

Вообще же есть новое предложение, опять же в туже тему - унификация - но пока без xml, короче - за основу берём тот же подход что и применяемый в разганичении прав - создание сущностей обеспечивающих разделение - аккаунты (групповые, пользовательские).
и так покажу на примере:
есть некий комплекс Xorg
в обычном своём поведении при установке данный комплекс распихивает свои файлы по каталогам
/etc
/bin
/usr/bin
/home/<user>
и другим

что я предлагаю:
перед установкой xorg запрашивает себе, условно назовём, "аппдомен" - генерируемый случайно уникальный идентификатор, например в таком виде 77b3-4f76-1c01-1a24
получив id комплекс начинает распихивать себя по каталогам: но везде перед своими файлами втыкается полученный ранее id
/bin/77b3-4f76-1c01-1a24/файлы и каталоги
/etc/77b3-4f76-1c01-1a24/файлы и каталоги
/lib/77b3-4f76-1c01-1a24/файлы и каталоги
/usr/bin/77b3-4f76-1c01-1a24/файлы и каталоги
/usr/local/77b3-4f76-1c01-1a24/файлы и каталоги

как вариант:
/bin/appdomains/77b3-4f76-1c01-1a24/файлы и каталоги
/etc/appdomains/77b3-4f76-1c01-1a24/файлы и каталоги
/lib/appdomains/77b3-4f76-1c01-1a24/файлы и каталоги
/usr/bin/appdomains/77b3-4f76-1c01-1a24/файлы и каталоги
/usr/local/appdomains/77b3-4f76-1c01-1a24/файлы и каталоги
в каждом каталоге лежит файл допустим .desc содержащий линейный конфиг вида:
app_id=77b3-4f76-1c01-1a24
app_title=Xorg
dir_title=Config Directory
app_version=7.1
dir_version=001
...

вот вкрадце и вся идея. !beer

для сохранения совместимости делаются ссылки на старые места, ну типа:
ln -s /etc/appdomains/77b3-4f76-1c01-1a24/xorg.conf /etc/X11/xorg.conf

в утилиты типа ls вносятся дополнительные параметры, для отображения дескрпшинов, хотя можно и не вносить, grep вполне сгодится.

плюсы такого решения:
1) сохранняется совместимость с POSIX (никто не забыт ни что не забыто 8) )
2) унифицируются место положение файлов каждой программы индивидуально
3) упрощаются установка, удаление, контроль приложений, сбор информации по ним, упрощаются возможности по поддержанию в рабочем состоянии нескольких версии какой либо программы с несколькими версиями сопутствующих данных
4) может ещё какие есть? 8)

минусы:
1) немножечко усложняется представление.
2) может ещё какие есть?

Не сказал про другие директории, но думаю развить мыль вполне посилам любому линуксойду.

хачу комменты 8)

[ Редактирование 20.09.2006 - 18:26:44 ]

ср, 20/09/2006 - 14:46

#16

RNZ

Не в сети

Зарегистрирован: 24/09/2010

Ещё можно ввести, на базе того что предлагаю, такую штуку как PgID в добавок к UID и GID. Т.о. можно отделить пользовательские аккаунты от аккаунтов программ. Хотя в этом нет такой уж большой необходимости, но как вариант...

ср, 20/09/2006 - 14:51

#17

maax (не проверено)

сюда: http://gobolinux.org/index.php?lang=ru_RU

вообще не уловил мысли, для чего сей балаган задумывается?

ср, 20/09/2006 - 15:02

#18

RNZ

Не в сети

Зарегистрирован: 24/09/2010

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

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

ср, 20/09/2006 - 17:02

#19

Vitls

Не в сети

Зарегистрирован: 21/09/2010

Тупая идея.

Мне как администратору-практику, эксплуатирующему системы будет НЕУДОБНО разбираться в xml. А если оно ещё и в дереве, это будет просто попа.

Мне удобно, что все конфиги положены в одном месте - /etc. Удобно когда каждое приложение имеет свой отдельный ЧИТАЕМЫЙ текстовый файл, который редактируется ЛЮБЫМ удобным мне редактором, локально или удаленно на ЛЮБЫХ каналах ЛЮБОЙ пропускной способности.

Существующая система имеет неоспоримое преимущество - она УНИВЕРСАЛЬНА.
[ Редактирование 21.09.2006 - 09:44:03 ]

Дело не в том как болезнь вылечить.
Дело в том как других заразить.

ср, 20/09/2006 - 17:57

#20

whitewarrior (не проверено)

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

ср, 20/09/2006 - 17:57

#21

RNZ

Не в сети

Зарегистрирован: 24/09/2010

Vitls, whitewarrior - читайте все посты пожалуйста, прежде чем постить
http://www.nclug.ru/forum_viewtopic.php?8.7718.0#11540
[ Редактирование 20.09.2006 - 18:09:20 ]

ср, 20/09/2006 - 18:00

#22

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]По анализировал, по ковырял, по думал - признал не состоятельность идеи. 8) Однако идею заценила microsoft 8) - похожее реализуется в vista'е. Но это так флюиды.

Вообще же есть новое предложение, опять же в туже тему но пока без xml,[/b]
http://www.nclug.ru/forum_viewtopic.php?8.7718.0#11540

Под "в туже тему" я понимаю "унификация"
[ Редактирование 20.09.2006 - 18:05:12 ]

ср, 20/09/2006 - 19:09

#23

probeerka (не проверено)

Хоть убейте, не могу понять, зачем сии переделки нужны... (сразу, конечно, не убивайте :-) )
Лучше было бы, чтобы ВСЕ дистрибутивы поддерживали LSB, чтобы не вспоминать, что где лежит в каждом конкретном дистрибе...

ср, 20/09/2006 - 21:38

#24

RNZ

Не в сети

Зарегистрирован: 24/09/2010

Убивать небудем 8)
Для того и предлагаю это, как все знают LSB поддерживают хреново, в разных дистрах по разному выдрачиваются. По сути я предлагаю нахер убрать ручное именование директорий по которым распределяется программа, пусть это делается автоматом, на уникальной основе. А userlike представление реализуется файлом описания лежащим в дирректории. Косвенный аналог можно подсмотреть в DNS - установление соответствия ip<->имя

чт, 21/09/2006 - 01:51

#25

maax (не проверено)

как раз в данном случае - gobolinux это и есть тоже самое, только вместо аппдомен используется более осмысленная комбинация названия пакета и его версии.. патч gobohide реализован в ядре.. кстати, интересно, что подразумевается под словом ось? так что теже яйца, вид сбоку :)

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

что подразумевается под установкой? ./configure; make; make install? как быть с бинарниками? кстати чем этот способ проще чем арчевское pacman -S bash для бинарников и makepkg -ci для портов? или уж простое apt-get bash от дебиана..

как я буду запускать bash? /usr/bin/qwerty-qwerty-qwerty-qwerty/bash? через симлинк? /usr/bin/bash? а если захочу пересесть на csh с удалением bash? бегать по иерархии файлов и убивать все что напоминает qwerty-qwerty? а потом еще вычислять линки и их тоже мочить? или будет утилита которая будет делать это за меня? дык, она и сейчас есть, pacman, dpkg, в другом контексте, без излишних симлинков, без каталогов а ля md5 через черточку, и соответствует lsb в той или иной степени... :)

идея gobolinux, однозначно :)

з.ы. Стандарт POSIX.1 определяет интерфейс программирования приложений (APIs), предназначенный для обеспечения переносимости исходных кодов приложения. Это не исполняемый код и не операционная система, это точное определение интерфейса программирования (с) POSIX® 1003.1 Frequently Asked Questions

чт, 21/09/2006 - 09:41

#26

Vitls

Не в сети

Зарегистрирован: 21/09/2010

> Vitls, whitewarrior - читайте все посты пожалуйста, прежде чем постить
"Вы были взвешены, вы были измерены и были признаны негодным" (с) Рыцарская сага.

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

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

То, что нынче существует десятки лет, прошло испытание временем. Пересаживясь с Linux на Unixware я, например, зная, что и то и то есть UNIX (и соответствует нормам POSIX) могу справедливо ОЖИДАТЬ, что: файлы настроек приложений лежат в /etc, приложения уровня системы лежат в /bin, прикладуха в /usr/bin и т.п. И самое главное они не требуют использования специальных средств для редактирования. Ваша система это подразумевает.

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

p.s. В догонку. Пример с named некорректный. У него один файл конфигурации /ets.named.conf, файлы описаня зон являются данными и справедливо хранятся в дереве /var.

p.p.s. А что вы будете делать в случае использования chroot окружения?
[ Редактирование 21.09.2006 - 09:50:33 ]

Дело не в том как болезнь вылечить.
Дело в том как других заразить.

Втр, 26/09/2006 - 11:43

#27

ElaDar (не проверено)

[quote=RNZ]
{skipped}
3) упрощаются установка, удаление, контроль приложений, сбор информации по ним, упрощаются возможности по поддержанию в рабочем состоянии нескольких версии какой либо программы с несколькими версиями сопутствующих данных

минусы:
1) немножечко усложняется представление
[/quote]
Несколько противоречиво, тебе не кажется?

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

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

Ситуация, когда на одном ПК жизненно важно держать разные версии одной программы - достаточно редкая. IMHO, идея интересна только в одном ключе - если ты хочешь САМОСТОЯТЕЛЬНО проверить свежую версию прежде чем внедрять обновление на всех "подшефных" компах. И то, если есть такие интересные вещи как SVN/Subversion, не проще ли будет подкрутить каким-либо образом в дерево файловой системы именно их? А еще есть CHROOT и Jails, а еще есть Xen и VMware... Мало что-ли?

Вердикт: интересно, полезно для углубления знаний о системе и программировании в ней но не жизнеспособно для широкого внедрения

Втр, 26/09/2006 - 14:53

#28

Ne01eX

Не в сети

Зарегистрирован: 20/09/2010

У-у-у господа, куда вы завернули. Прям Компутерные Чегивары...

>>Лучше было бы, чтобы ВСЕ дистрибутивы поддерживали LSB, чтобы не вспоминать, что где лежит в каждом конкретном дистрибе...

Нехрен скакать по дистрибам. Это бессмысленно и глупо. Вот только не надо чесать, что в одном дистрибутиве проще одно делать, а в другом другое, лажа все это... Это мое ИМХО и конечно же ваше дело сколькими дистрибутивами пользоваться.

сб, 07/10/2006 - 14:00

#29

RNZ

Не в сети

Зарегистрирован: 24/09/2010

2 Vitls
- "Первая причина уже была мной упомянута - неудобство практического использования. Вторая - невозможность интеграции в уже существующие системы (подобный путь уже опробован в ALT при переходе с net-scripts на подсистему etcnet, тем не менее обратная совместимость у них есть)."
Неудобство? Я пока не предлагаю сиюминутно это реализовывать. С другой стороны понятие о удобстве у каждого своё. И чуть ниже я приведу пример как можно это сделать удобным в глазах большинства. И почему это на ваш взгляд это невозможно интегрировать в существующиее системы?

- "В догонку. Пример с named некорректный. У него один файл конфигурации /ets.named.conf, файлы описаня зон являются данными и справедливо хранятся в дереве /var."
Вы не поняли о чём речь, я сопоставляю не с конкретной реализацией named, а провожу аналогию между схемами установления соотвествия: id<>appname как аналог ip<>domainname.
Пример:
в /etc/ лежит некий файл допустим c названием installed допустим следующего содержания
bind-9.3.2 {1233-434a-111c-a124}
wget-1.10.2 {13cf-236d-dc22-df14}
samba-3.0.23a {6341-7184-892d-0c89}
Xorg-7.1 {77b3-4f76-1c01-1a24}
Xorg-6.9 {5393-76e6-0d1a-6e4f}
далее -> http://gentoo.ru/node/4212#comment-21441

2 ElaDar
- "Несколько противоречиво, тебе не кажется?"
Ну это по началу такое может показаться, но в целом представление можно сильно упростить используя подобный описанному тут способу http://gentoo.ru/node/4212#comment-21441

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

По поводу к чему всё это - один из примеров http://gentoo.ru/node/4212#comment-21947
А вот интеграция svn для подобного применения... - ИМХО, уж очень сложное решение.

более обширно тема, а точнее вторая её инкорнация, обсуждается на http://gentoo.ru/node/4212?comments_per_page=90

И снова насчёт унификации самих конфигов ( потому как чешется 8) ) - почему бы не привести, всё же, все конфиги к виду подобному следующему:
"name1"::"key1"="value":"key2"="value":
"name2":"name1":"key1"="value":"key2"="value":
, то есть на простом имеем следующий конфиг:
section "name1" {
"key"="value"
...
}

section "name2" parent "name1" {
"key"="value"
...
}
?
Вообще думаю нафиг не нужно иметь кучу редакторов для того что бы редактировать конфиги, лучше пусть будет всего один и везде на всех дистрах. Например назовём его сfged.
Если вызвать так
cfged /etc/.../xorg.conf
то увидим userlike вариант:

section "name1" {
"key"="value"
...
}

section "name2" parent "name1" {
"key"="value"
...
}

если точно знаем значения которые надо поменять пришем например так:
cfged /etc/.../xorg.conf
"name1"::"key"="value";"name2":"name1":"key1"="value":"key2"="value":
а уже cfged сам всё запишет, переносы можно оформлять как обычно обратным слешем \

здесь можно получить ещё один интересный момент, одна секция может принадлежать сразу к нескольким другим секциям:
т.е.
section "name1" {
"key"="value"
...
}

section "name2" {
"key"="value"
...
}

section "name3" parent "name1, name2" {
"key"="value"
...
}
или

"name1"::"key1"="value":
"name2"::"key1"="value":
"name3":"name1,name2":"key1"="value":"key2"="value"
Конешно тут могут быть свои траблы типа циклические зависимости, но думаю если это будет делать "умная" тулза, всё будет в "ажуре". 8)

почистил от [div class='indent']

[ Редактирование 09.10.2006 - 23:57:35 ]

Пнд, 09/10/2006 - 08:53

#30

Vitls

Не в сети

Зарегистрирован: 21/09/2010

Блин...
Ну сколько можно тыкать вас лицом в то, что вы на задачу смотрите с точки зрения программиста, но не пользователя.
Для систем автоматизированного управления программным комплексом такой метод возможно и подходит, но для реальной ежедневной практической работы в разнородной и распределенной среде - НЕ ПОДХОДИТ.

Дело не в том как болезнь вылечить.
Дело в том как других заразить.

Пнд, 09/10/2006 - 13:59

#31

RNZ

Не в сети

Зарегистрирован: 24/09/2010

Не надо меня никуда тыкать.
Я на задачу сморю с обоих сторон.
И как раз для пользователя и предлагаю упрощение.
И в реальной системе, человек хочет просто пользоваться программой и не заботится о её установке.
Вы никогда не видели windows пользователя который забил весь диск C, и парит всех вопросами - "как?", "что?", "куда?", "почему?", "зачем?" ?

Почему "для реальной ежедневной практической работы в разнородной и распределенной среде - НЕ ПОДХОДИТ"? Каковы причины? Что мешает?

Если Вы имеете в виду момент с исчерпанием ёмкости и необходимости размешеняи программ по другому логическому/физическому пути.
То в этом случае есть несколько выходов из положения:
1) lvm - очень хороший метод
2) --perfix - не самый лучший, но как вариант исключать нельзя
3) Метод который я вижу в случае если применение lvm не возможно - можно реализовать например автопрефикс, т.е. генератор app-id проверяет свободную ёмкость при каждой установке, если ёмкость близка к исчерпанию порога, который можно задать заранее, то предлагается указать для всех устанавливаемых в последующемм программ, при достижении лимита, использовать другое местоположение. Можно например и заранее указать другое местоположение и лимиты.

Пнд, 09/10/2006 - 16:08

#32

maax (не проверено)

из всего написанного я так и не понял самого главного видимо:

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

проскакивало предложение, что это упрощает установку для пользователя.. как? я пользователь, меня не волнует где все это лежит.. итак:

я пользователь арчлинукса, устанавливаю (ну или обновляю) csh:
pacman -S csh

надоел csh..
pacman -R csh

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

Пнд, 09/10/2006 - 16:23

#33

whitewarrior (не проверено)

2RNZ:

http://gentoo.ru/node/4212#comment-21947
>>унифицируются место положение файлов каждой программы индивидуально

Не, ну я понимаю, конечно, некуда силушку приложить... Но это ж изврат! НУ НИКОГДА НЕ БУДЕТ мне лично, ИМХО, удобно работать с такой систмой. Я не программер. Электронщик я. И для меня, как для конечного пользователя, удобна система, существующая ныне. Все прозрачно, никакого геморроя. А Ваш подход, мне кажется, добавит сложностей в и без того нелегкую для новичков linux-систему. Что мне теперь, чтобы отредактировать конфиг, нужно детально изучить еще пару-тройку умных книжечек? Да мне нынешние конфиги милее. Открыл его тем же nano и крути как хошь. В общем, читал и на gentoo.ru, и здесь... Не пойму, для чего эти сложности. И, без наезда, есть товарисч один, RooTest зовут. Так он тож всякой фигней маялся... Потом затих, делом занялся :-)

P.S. >> Я на задачу сморю с обоих сторон.
>> И как раз для пользователя и предлагаю упрощение.

А у пользователя спросили, нужно ли ему такое упрощение???
[ Редактирование 09.10.2006 - 16:25:02 ]

Пнд, 09/10/2006 - 21:00

#34

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]maax[/b]
Вообще говоря, чем обусловенно существоание менеджеров пакетов в linux? Необходимостью контролировать зависимости. Установка программы с помощью менеджера - снимает с пользователя необходимость ручками контролировать зависимости, в этом и есть основная задача менеджера. Я не предлагаю отказываться от репозитариев, я предлагаю усовершенствовать подход установки программ в систему.
Теперь рассмотрим pacman или работу менеджера.
Какие минусы в случае использования приведённой комманды pacman -S|R csh:
1) пользователь должен знать синтаксис pacman.
2) что делать если я хочу установить программу которой нет в репозитории?

Развивая мою идею:
1) Если взять в расчёт синхронизацию с репозитарием, можно определить список всевозможного программного обеспечения и установить статус локально -[не]установлен. типа:
bind-9.3.2 {1233-434a-111c-a124}
wget-1.10.2 {}
samba-3.0.23a {}
xorg-7.1 {77b3-4f76-1c01-1a24}
соотвественно, пустые {} (их может и вообще не существовать) указывают на состояние НЕ Установлен.
т.е. набрав
samba<tab> дорисуем -3.0.23a
а строкой ниже увидим samba-3.0.23a {not installed}
жмякним <enter> выбираем действия

You have next commands to manipulate with samba-3.0.23a
depends(d) - list all direct dependencies
check(c) - ...
install(i) - ...
fetch(f) - ...
pretend(p) - ...
...
other commands
wait for command:

хотим обновить/удалить
тоже самое жмякаем
samba-3.0.23a<enter>
и нам на выбор варианты
Do you want samba-3.0.23a to reinstall|update|delete|cancel? [r|u|d|c]

Если нам надо без вопросов ставить, то можно например предустмотреть
samba-3.0.23a --help
и среди всего списка команд добавить
--silent или --quiet

Это на Ваш взгляд сложнее чем pacman -S|R samba?

Забыл добавить:
Кроме того можно ставить пакет который никогда не был в репозитории, но который подчинен общим правилам, с тем лишь нюансом, что зависмости описаны в самом пакете (что можно и нужно взять за правило для всех пакетов вообще). Это в пику того что не продвинутому пользователю, например всё той же gentoo, совсем не обязательно ждать очередного ebuild'a для его любимой программы которую он обновляет чаще чем ментейнеры репозитория.

[b]whitewarrior[/b]
- Как сказал кто-то - "Никогда не говори "никогда"" 8)
Где именно усложнится жизнь у пользователя?
Если говорить о сложностях жизни новичков, то в linux так или иначе сегодня каждый вынужден знакомиться с консолью, новичку это нужно? Новичёк в windows узнаёт о консоли и её полезности, лишь когда у него в голове накопится опредеённая критическая масса информации, например: спустя год после покупки компа, у него накроется всё, к нему придёт сосед/друг который воткнёт ему xp на fat32 извращенческим способом через win98, спустя какоето время новичку вдруг станет известно что пользование fat32 для winxp есть вред, он ещё не будет толком понимать почему, но он где-то услышит что её можно сконвертировать, начёт спрашивать, и хорошо если спрашивать у сведущеих людей, но обычно это тот же плоский сосед/друг, который экстремально научился играть в lineage, который даст ему бутовый диск с pgmagic или acronis, ну естественно (по закону подлости) во время конвертации подстанция грохнется, а упс если он вообще есть, держит тока 10 минут, а конвертировать ещё ой как долго, итог инфа - запорота. Затем новичёк, под наставничеством своего доброго соседа/друга, начнёт учиться разбивать винт с помошью всё тех же acronis и pqmagic, причём будет делать fat32, затем узнает что есть команда sys c: (можно сказать первое знакомство с консолью), освоит что диск для загрузки должен быть активным, увидит norton/vc, отчасти осознает словосо directory|каталог|папку научится копировать файлы в norton|vc, и наконец созреет для установки win98 ткнув из нортона setup.exe, а уже из под неё благговейно будет наблюдать за обновлением до winxp, потом, спустя пару походов в какойнибудь сервис центр по различным поводам, ему кто-то скажет, что для всего было достаточно иметь загрузочный диск с winxp, а для конвертации можно было использовать консольную команду convert c /fs:ntfs, он её бережно запишит на бумажку и пойдёт домой пробовать, так как winxp у него по прежнему висит на fat32. Тут он и начнёт своё новое знакомство с консолью. И может вырастит до linux пользователя, а может плюнит на всё и будет играть в свой любимый КС. Это так флюиды по поводу лёгкости.

В основу linux на мой взгляд ставится не лёгкость освоения/пользования, а продуктивность.

Для редактирования можно использовать (если отмести возможность совместимости), текущий подход, с некоторыми дополнениями:
ну например я хочу ручками отредактировать xorg.conf
находясь в любом каталоге системы пришу
vim xorg<tab> если установлена одна версия xorg дописывается например "-7.1/" жму <tab>/
bin etc tmp lib usr/bin var
дописываю e жму <tab> получаю vim xorg-7.1/etc/ ещё раз жму <tab> вижу список конфигов
xorg.conf
xorg.conf-fglrx
xorg.conf-nv
дописываю xorg.conf
вижу
vim xorg-7.1/etc/xorg.conf жму <enter>
редактирую.
Есть сложности? Требуется много вумных книжек? Истиный путь /etc/77b3-4f76-1c01-1a24/xorg.conf - скрыт. Да и нафиг его знать, достаточно знать имя установленной в системе программы и дальше использовать для манипуляций распределённую иерархию самой программы, а не шарить по всей систему в поисках конфигов lib'ов, бинарниоков, логов и т.д которые кстати сказать могут именоваться как угодно, фактически можно иметь для всех программ одинаковую иерахию, т.е. вместо например xorg.conf может сущестовать только conf
и для редактирования можно использовать строку
vim xorg-7.1/etc/conf
или
vim apache-2.1/etc/conf
или
vim mysql-5.2/etc/conf
Думаю теперь унификация видна не вооруженным глазом.
Но я бы предпочёл что бы для редактирования использовалась бы всего одна единственная утилита, которая по крайней мере умела бы валидировать конфиг на предмет соответствия синтаксиса.

Пользователя вообще редко о чём либо спрашивают, что тоже не есть хорошо, но я всего лишь предлагаю, а не насаждаю как microsoft 8)

[ Редактирование 10.10.2006 - 11:11:14 ]

Втр, 10/10/2006 - 09:04

#35

whitewarrior (не проверено)

>> Пользователя вообще редко о чём либо спрашивают, что тоже не есть хорошо, но я всего лишь предлагаю, а не насаждаю как microsoft 8)

Вот на этой оптимистичной ноте... Вообще, конечно, все это флейм. Возможно появление нового дистра, в котором это будет осуществлено... Но, к примеру, у меня дженту. Криво обновил систему и мне надо ее поправить. Гружусь с liveCD, начинаю ковырять, а вместо нормального пути к конфигам какая-то хня из стиля аля "маздайный реестр"... Да я сразу застрелюсь. :-) Еще вопрос: Зачем юзеру несколько версий xorg?

Втр, 10/10/2006 - 09:31

#36

Vitls

Не в сети

Зарегистрирован: 21/09/2010

>Развивая мою идею:
>1) Если взять в расчёт синхронизацию с репозитарием, можно определить список всевозможного программного обеспечения и >установить статус локально -[не]установлен. типа:

Как это сочетается у УЖЕ существующими средствами контроля целостности дистрибутивов (например yast, apt-get)?
Отвечаю никак. А вот следование LSB - очень даже помогает унифицировать расположение файлов в дереве каталогов.
На менеджере пакетов лежит обязанность отслеживания программных зависимостей. Пользователю же проще выучить одну команду для установки-сноса приложения. Остальное не его забота. Если пользователь дорос до того, что сам собирает приложение - извольте использовать --prefix. А еще лучше прочесть LSB и установить в /usr/local.
Вывод: LSB - это наше всё.

Дело не в том как болезнь вылечить.
Дело в том как других заразить.

Втр, 10/10/2006 - 10:50

#37

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]whitewarrior[/b]
Во флейм этот топик преврашают высказывания подобные Вашему, потому как Вы и другие изначально отвергаете идею, даже не пытаясть хотя бы немного развить её, Вас после этого можно спокойно сравнить с виндузятником 8).
Вот, в упомянутом восстановлении после сбоя, Вы привели пример, но даже не подумали о том что бы просто дорисовать пару возможные действия. Для такого дистра будет свой livecd для восстановления который даже в случае потери реестр-файла, точно так же как и сам дистрибутив, сможет восстанавливать отображение userlike инфы для каждой программы основываясь на инфе которая лежит в каждом каталоге программы.
Xorg и юзеры бывают разные. Но зачем например пользователю, mysql 3 и mysql 5? А может он ещё софт не переписал под работу с 5?

[b]Vitls[/b]
Честное слово yast, apt-get и другие мне как-то до лампочки, как и той же gentoo. А LSB нарушают все кому ни поподя, я не предлагаю её нарушать. Предлагаемая концепция прекрасно вписывается и в рамки LSB, хотя и их может стоит расширить. Пользователь учить команды не хочет. Команды пользователь учить начинает как раз когда созреет.
Вывод: Вы нифига не пытаетесь вникнуть в идею, развить её. Может быть потому что Вам лень, может потому что Вы не способны, а может Вам некогда. Но вот на ответ Вы время находите. 8)

[ Редактирование 10.10.2006 - 11:06:01 ]

Втр, 10/10/2006 - 12:32

#38

whitewarrior (не проверено)

Смотрим [link=http://gentoo.ru/node/4212 ]здесь[/link]. Очень интересная ветка. Вы поймите, что ни один гентушник с вами не согласится. Ни за что. И я в том числе. В конце концов, у меня есть слоты... Далее.

>> Xorg и юзеры бывают разные. Но зачем например
>> пользователю, mysql 3 и mysql 5? А может он ещё софт не
>> переписал под работу с 5?

Ну-ну. Подразумевается, что ПОЛЬЗОВАТЕЛЬ пишет СВОЙ софт для работы с пятым мускулем? Или это просто игра слов? Но, еще раз, туда же, в дженте есть слоты.

>> Вас после этого можно спокойно сравнить с виндузятником 8).

Угу, лехко. Сравнивайте. Не убудет. Только с маздая я ушел уже довольно давно. А вот воспоминания о ковырянии в убогом реестре, который толком-то и не документирован... Тьфу, противно аж! Можно сказать, текстовые конфиги линукса с кучей экзамплов показались мне сказкой! Да, нужно знать ангельский. Чуток. Но можно и не знать - словари еще никто не отменял.

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

Типа того. Только вот, возможно, такое отвергание приблизит вас к более мудрому решению? Вы готовы создать принципиально новый дистр? Основываясь на своих идеях. Осуществить грамотную поддержку и путёвое обновление? Я к тому, что встраивать это в существующий, ну, с моей колокольни, дженту, никто не согласится. Это моя точка зрения, как, собственно и высказывающихся [link=http://gentoo.ru/node/4212 ]тут[/link].

И, собственно, на посошок :-)
>> в случае потери реестр-файла

Мне, сравниваемому с виндузятником, следует от смеха икать под столом? Ну да ладно, от маздая я ушел, но новости-то читаю. Даже мелкомягкие осознали нецелесообразность реестра куском... А в линуксе теперь бедет большущий такой файл, громоздкий и неудобный, для редактирования которого надо будет еще и xml знать нехило? И называться он будет гордо-гордо, как в маздае: ФАЙЛ РЕЕСТРА. LOL, товарисчи, lol!!!

Втр, 10/10/2006 - 13:44

#39

Dumus

Не в сети

Зарегистрирован: 17/09/2010

Хотелось бы увидеть практическую реализацию, чтоб пощупать-сравнить + xml - не лучший выбор...

Мой микроблог: http://juick.com/Dumus/

Втр, 10/10/2006 - 14:42

#40

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]whitewarrior[/b]
"Вы поймите, что ни один гентушник с вами не согласится. Ни за что. И я в том числе. В конце концов, у меня есть слоты... Далее."
Почему? В принципе я и сам могу ответить - всё достаточно прозаично - сложно менять привычки. О слотах ниже.

"Ну-ну. Подразумевается, что ПОЛЬЗОВАТЕЛЬ пишет СВОЙ софт для работы с пятым мускулем? Или это просто игра слов? Но, еще раз, туда же, в дженте есть слоты."
- Подразумевается - пишет свой софт. [link=http://gentoo.ru/node/4212 ]Тамже[/link] есть почему слоты я считаю не самым лучшим методом.

"Угу, лехко. Сравнивайте. Не убудет. ..."
- Ну я хотел этим сказать о поведениии и привержености, и совсем не намекал на Ваше отношение к виндоуз, и тем более момент слезания с него 8). А насчёт текстового конфига, допустим перед Вами xorg.conf - пустой, сколько Вам понадобится времени, что бы осознать какое содержимое должен он включать при условии что вы новичёк?
Приведу более живой пример, есть fusesmb, допустим fuse включено в ядро (грузится монолитно или подгружается не важно), установили fusesmb, сделали как написано в readme fusesmb ~/smbnet, обнаружили что нам не выдают запрос на ввод логина/пароля к домену, начали искать конфиг что бы воткнуть аутентификацию по керберос, перерыли пол компа, а не нету нигде конфига! надо же fusesmb работает по умолчанию, идём в доку читаем, создаём конфиг, заполняем. это к тому что с конфигами так же надо читать кучи доки и ной раз просто до ужаса как много. А всегдали это нужно?

>> изначально отвергаете идею, даже не пытаясть хотя бы
>> немного развить её
"Типа того. Только вот, возможно, такое отвергание приблизит вас к более мудрому решению? Вы готовы создать принципиально новый дистр? Основываясь на своих идеях. Осуществить грамотную поддержку и путёвое обновление? Я к тому, что встраивать это в существующий, ну, с моей колокольни, дженту, никто не согласится. Это моя точка зрения, как, собственно и высказывающихся [link=http://gentoo.ru/node/4212 ]тут[/link]."
- По вашему получается мудрым решением является бросить всякие потуги что-ли либо творить?
Для создания дистрибутива я не готов, потому и ищу поддержки, у меня нет достаточных ресурсов во времени, не достаточно знаний, да и кушать мне надо. Но я думаю позже при благоприятных условиях я начну всё же стоить дистр, причём хочется увязать всё с системой портов от gentoo, но это работа не одного-двух дней. Что касается "поддержку и путёвое обновление" - тут вообще пока кол-во мысли не сильно ушло от нуля.
С другой стороны gentoo достаточно "живой" дистрибутив который изменяется много динамичнее других дистров, при это обладает огромной поддержкой со стороны профессионалов. Так почему бы не протолкнуть идею в gentoo, при условии что идея будет реально взвешена и подвергнута подробному анализу? Хотя конешно я предпологаю что запуска свое го дистра будет в разы более легким путем.

>> в случае потери реестр-файла
"Мне, сравниваемому с виндузятником, следует от смеха икать под столом? Ну да ладно, от маздая я ушел, но новости-то читаю. Даже мелкомягкие осознали нецелесообразность реестра куском... А в линуксе теперь бедет большущий такой файл, громоздкий и неудобный, для редактирования которого надо будет еще и xml знать нехило? И называться он будет гордо-гордо, как в маздае: ФАЙЛ РЕЕСТРА. LOL, товарисчи, lol!!!"
- Эх... Опять же не фига не вникая льёте кислотой...
Я уже сказал что в предлагаемой концепции, реестр (пусть будет так, это слово вполне отражает функциональность), не является сверхнеобходимой сущностью. По сути он является просто списком. Второе, пользователю его редактировать не нужно в принципе, всё должно делаться автоматикой. Третье, резервирование информации реестра всегда осуществляется в каталогах программы, т.о. можно всега перестроить реестр заново: выкачав последний список пакетов и основываясь на установеленном софте. Весь сакральный смысл реестра, сводится к упрощению установки и к ускорению отображения информации о пакетах и вся его его необходимость на этом и кончается. Кроме того, я уже [link=http://www.nclug.ru/forum_viewtopic.php?8.11568]сказал[/link] что использование xml не предпологается, что ещё раз свидетельствует о том что Вы не читаете толком ни этот топик, ни топик на gentoo.ru и внятно не сопоставляете.

[b]Dumus[/b]
О xml уже сказал и не раз.
А что бы пощупать, читай текст выше.
8)

[ Редактирование 10.10.2006 - 14:53:35 ]

Втр, 10/10/2006 - 16:28

#41

maax (не проверено)

2RNZ:

мененджер софта служит как минимум для двух вещей, установка и удаление, все остальное по определению фичи, в том числи и поддержка зависимостей.. например pkgutils из Crux не поддерживают зависимости..

теперь далее:
1. пользователь должен по определению знать синтаксис установки пакета, это раз, во-вторых, как Вы сами сказали никто не отменял --help, так что pacman --help работает.
2. а вот тут уже интереснее.. вообще для пользователя арчлинукса выхода два: написать pkgbuild самому, отправить запрос в комьюнити aur..

а теперь в продолжение второго пункта.. представим что создан инструментарий Вашей идеи.. что имеем далее? каждый разработчик будет должен изменить инсталяционные скрипты своего ПО, а теперь дружно представим все ли на это пойдут? пища для размышлений: все ли ПО использует комбинацию ./configure & make & make install? exim, strongswan, да что там говорить, ядро linux конфигурятся/компилятся/устанавливаются иначе :) опять же уместно напомнить о automake|autoconf, не все разработчики пользуются этими утилитами..

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

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

Втр, 10/10/2006 - 18:20

#42

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]maax[/b]
Опять двадцать пять.
Я не жду что идея найдёт отражение в умах сразу.
1) ИМХО - Пользователь не обязан знать синтаксис установщика не под каким из определений, ну не нужно ему это. Почему Вы думаете графические интерфейсы, мастера, кнопочки, листбоксы и комбоксы приобрели всеобщую популярность? Яркий пример windows. В ms так же дальновидно рассмотрели подход к установке приложений, они не стали плодить менеджеров (хотя может и стоило) - запусти и устанавливай - всё, то как программисты ms реализовали остальное оставим в стороне, изначально подход был выбран верно - пользователь драгоценное существо которе приносит деньги и надо его беречь и стараться не нервировать 8).
--help вообще тоже задвинуть, пусть вылазает по enter:
samba<tab>-3.0.23a<enter>
You have next commands to manipulate with samba-3.0.23a
ask(a) - ...
breake(b) - breake install
depends(d) - list all direct dependencies
check(c) - ...
install(i) - ...
fetch(f) - ...
pretend(p) - ...
quiet(q) - silent install, you may run install in command line with param -q, example: samba-3.0.23a -q
...
wait for command:

2) Получается забота о адаптации программы для дистрибутива ложится на плечи пользователя, т.к. писать pkgbuild/ebuild или отправить запрос в комьюнити - есть лишние телодвижения для пользователя.

Ваш вывод скоропостижен, идея не так уж и утопична. Ведь существование rpm, apt-get, portage, того же pacman, gtk, qt, kdelibs и т.д. и т.п. - не является утопичным, несмотря на тот факт что все они вносят свои коррективы в способы/методы написания/установки программ/пакетов. То что одни пользуют install.sh, другие make & make install, третьи automake|autoconf... ну что-ж делать, это уже выбор лично каждого, но тут я вижу другие причины разношерстности и первая из них - отсутсвие должной унификации в сборке и установки программ, т.е. возвращаемся к тому что унификация нужна и одну из идей я предлагаю.

Ещё раз повторяю - я не предлагаю отказываться от репозиториев. На мой взгляд их существование очень удобно и полезно.
Если уж подходить к установке не "родных" пакетов - в системе вполне могут существовать конвертеры пакетов для установки, причём они так-же могут работать автоматом.
И что Вы вцепились в симлинки? По моему мнению их стоит использовать только для совместимости, в перспективе возможно от них можно будет избавиться вовсе (при условии что предлагаемая концепция будет продвинута в жизнь и наберёт обороты).

[ Редактирование 10.10.2006 - 22:10:55 ]

Втр, 10/10/2006 - 22:07

#43

maax (не проверено)

2 RNZ:

1. ну во-первых синтаксис команд pacman'a, dpkg, apt-get и т.п. зачастую интуитивно понятен, и я что-то не встречал сложностей у пользователей, а насчет того нужно это или не нужно, тут наверно правильнее доверить это пользователю.. для одних хорошо работать и устанавливать ПО из консоли, для других есть гуишные обвесы для таких менеджеров софта.. и не дело примешивать сюда графические интерфейсы, мастера, кнопочки и иже с ними, это уровень представления информации, а также улучшение интерактивности непосредственно ПО.. насчет винды, опять же сравнение неправильное, не вижу никакой принципиальной разницы в этом отношении, что там что тут по сути одно и тоже.. или Вы с этим не согласны? если нет, то в чем конкретно?

2. в случае написания ebuild/pkgbuild забота конечно ложится на плечи пользователя, но этим он делает вклад в развитие и распространение свободного ПО, что не так уж и плохо... в противном случае на плечи пользователя никакая забота не ложится... и если отправить запрос в коммьюнити это лишнее движение, то чтож ленивые могут подождать..

rpm, apt-get, pacman сами подстраиваются под ПО, никаких корректив они в "способы/методы написания/установки программ/пакетов" не вносят, точно так же как не вносят gtk, qt, kdelibs, потому что они предоставляют библиотечные функции для построения графических интерфейсов, то бишь ими можно пользоваться, а можно и не пользоваться...

Вы ошибаетесь по поводу причин разношерстности, многие разработчики поддерживают не только Linux-платформу, но и FreeBSD, Solaris, Windows и другие платформы, Вы планируете всех унифицировать? кроме этого, сборку унифицировать Вам не удастся однозначно, в ходу более 30 языков программирования, существует много подходов, более того, под один язык может быть несколько компиляторов, некоторые программные разработки предлагают свой инструментарий для разработки так называемых плугинов, в apache это apr, продукты mozilla предоставляют nss, и так далее.. так что в дальнейшем не говорите об унификации сборки, это просто несерьезно..

а я еще раз повторяю: Вы просто не сможете отказаться от репозиториев, и в этом случае Ваша идея не что иное как дистрибутив с новым менеджером софта, не предоставляющим ничего нового из того что уже есть.. конвертеры не родных пакетов? пощупайте в debian'е пакет alien..

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

ср, 11/10/2006 - 15:44

#44

Vitls

Не в сети

Зарегистрирован: 21/09/2010

>Почему Вы думаете графические интерфейсы, мастера, кнопочки, листбоксы и комбоксы приобрели всеобщую популярность? Яркий пример windows. В ms так же дальновидно рассмотрели подход к установке приложений, они не стали плодить менеджеров
1. Хе... Самое интересное, что универсальный набор для установки любого приложения был написан... не MS, а другой конторой. Продукт InstallShield еще с 1992 года позиционировался как средство для работчиков ПО, позволяющее установить приложение в среде Windows.
2. Если речь зашла о графическом интерфейсе пользователя. Солвременные дистрибутивы (сюрприз!) УЖЕ имеют необходимые средства для установки\обновления, которые НЕ требуют знания командной строки.
3. Ваша идея предполагает _спецификации сборки_ ПО? Как в случае rpm-дистрибуции - это spec-файлы, в которых устанавливаются опции компиляции, зависимости, инсталляции.
4. Некий автор написал программу. Некий распространитель решил, что ее можно упаковать в rpm. Для этого: анализируется процесс сборки и инсталляции программы, пишется spec, собирается пакет. ПО готово к распространению. Спрашивается: на каком этапе и кто программу должен подгонять к etc-xml?

Дело не в том как болезнь вылечить.
Дело в том как других заразить.

чт, 19/10/2006 - 22:02

#45

maax (не проверено)

жаль что идея высохла, у меня еще куча аргументов, которые приберег на последний удар :)

пт, 20/10/2006 - 20:29

#46

Sheridan

Не в сети

Зарегистрирован: 20/09/2010

XML не нужен. Точка.

сб, 21/10/2006 - 00:38

#47

RNZ

Не в сети

Зарегистрирован: 24/09/2010

[b]Vitls[/b]
1) Не существенно
2) А существуетли linux дистрибутив в котором пользователю не придётся изучать параметры командной строки, идеологию размещения файлов, систему.
3) не исключено, хотя фактически это мало необходимо
4) забегание вперёд, но в целом всё тоже самое может быть применено с тем лишь добавлением что для распихивания файлов из rpm, будет так же запрашиваться аппдомен(id).

Вы может перечитать http://www.nclug.ru/forum_viewtopic.php?8.7718.20 и на время отросить etc-xml? Идея которую я предлагаю созвучна с etc-xml только в слове - унификация.

[b]maax[/b]
Идея не высохла. Сейчас я больше занят другими делами. Потому над идеей пока просто размышляю, делаю наброски для реализации иногда, взвешиваю те или иные аспекты, учусь, тот же ArchLinux поковыриваю временами.
Насчёт "беззаветной веры" и выше - по позже сформулирую ответы.

[b]Sheridan[/b] http://www.nclug.ru/forum_viewtopic.php?8.7718.20
[ Редактирование 21.10.2006 - 00:39:17 ]

сб, 21/10/2006 - 17:51

#48

maax (не проверено)

надеюсь что идея не умерла, а то уж слишком много я еще хотел сказать :)

вс, 22/10/2006 - 15:52

#49

Sheridan

Не в сети

Зарегистрирован: 20/09/2010

Я еще раз повторяю:
Вопервых с xml лишние затраты ресурсов на разбор
Вовторых намного менее удобное редактирование конфигов
в третих необходимость переделки уже существующего софта
и в четвертых необходимость переконфигурирования настроенной и полностью рабочей системы
Оно нам надо? Забудьте про xml.

вс, 22/10/2006 - 23:28

#50

RNZ

Не в сети

Зарегистрирован: 24/09/2010

1 и 2 - Sheridan - честное слово, Вы меня удивляете! Такое впечатление что Вы прочтитали только певую страницу топика, а дальше читаете только самые последние посты!?! Или Вы читаете сквозь шифромаски что-ли??! Я Вам уже в который раз даю ссылку по адресу которой сказанно - [b]... в туже тему но пока БЕЗ xml !![/b]
http://www.nclug.ru/forum_viewtopic.php?8.7718.20
http://www.nclug.ru/forum_viewtopic.php?8.11568
Читаем пост http://www.nclug.ru/forum_viewtopic.php?8.11802
с обзаца начинающегося словами - И снова насчёт унификации...

3 и 4 - всё меняется когда нибудь
[ Редактирование 22.10.2006 - 23:34:43 ]

Пнд, 23/10/2006 - 07:23

#51

Ne01eX

Не в сети

Зарегистрирован: 20/09/2010

Много читал, много думал, много пил после этого. Пара вопросов возникла, интересуюсь их задать.

1. Если честно, то я ни фига не догоняю как системы управления пакаджами относятся к конфигам, скажем к конфигам программного пакета fluxbox? Или apache, если он вам так больше нравиться.

2. Какие действия для приведения семантики конфигурационных файлов к пропагандируемому вами виду вы уже предприняли? Скажем сколько вам нужно времени, чтобы привести к данной схеме, с ХЭМЛ или без него, тот же fluxbox или apache?

/etc-xml

Вход в систему

Найти

Навигация

Теги

Новое на форуме

Последние комментарии

Лучшее от Линуксцентра: