Реклама
.
Рекламки



Авторизация






Последние комментарии
#1
2023 пишет: » Запостите:

s3r [точка] ru/stavka-tolko-na-linuks-et... (18.03.2023)
// ОСТОРОЖНО: ВИНДОФИЛИЯ!
#2
бронедрочец пишет: » В костылинуксе порядок таков: нужен нормальный кал... (02.03.2023)
// Обзор калькуляторов в GNU/Linux
#3
Линупсодав пишет: » Костылинупс на десктопе не взлетит без прикладнухи... (13.02.2023)
// ОСТОРОЖНО: ВИНДОФИЛИЯ!
#4
admin пишет: » БоЗяН, ожидаемо. (30.01.2023)
// ReactOS 0.4.1
#5
БоЗяН пишет: » Хех. Чёт делать было нечего - дело было вечером)))... (29.01.2023)
// ReactOS 0.4.1
Цитаты
За использование return как имени макроса - отдельный приз в номинации «повелитель граблей» получает <ххх>



Предложены радикальные изменения в работу сети в Linux | автор: Luca | 4 сентября 2012

Категория: GNU/Linux

Olaf Kirch, участник коммьюнити SUSE, матерый linux-хакер (с начала 1990х) и автор неоднократно переиздававшихся книг по настройке и администрированию сети в linux, предложил сегодня на рассмотрение сообщества Fedora свою давно вынашиваемую идею — полностью переписать userspace стек управления сетью в linux, учитывая накопленный за два десятка лет опыт. Новая архитектура сетевой подсистемы позволит, как считает Olaf, полностью отказаться как от неподдерживаемой мешанины bash-скриптов (давным-давно устаревших ifup/ifdown и прочего), так и от критикуемого за сложность и такую же неподдерживаемость NetworkManager. В предложенной им архитектуре сетевой стек четко разделяется на несколько слоев, сущности внутри которых конфигурируются с помощью XML.









Предложение уже получило как критические отзывы (от инженера Red Hat и текущего мэйнтейнера busybox, Denys Vlasenko), так и сдержанно заинтересованные ответы.

источник



      ВНИМАНИЕ !
Возможно что-то уже неактуально. Обращайте внимание на даты !
Эта статья опубликована 4 сентября 2012-го года !



Голосов: 3


Прочитано 4091 раз и оставлено 42 комментариев.





Комментарии посетителей

#1. Luca

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

Аргументы почему XML - это плохо потрясают своей глубиной! "Потому что его читать перед сном плохо".

#2. pavel2403

pavel2403
Luca написал:
Аргументы почему XML - это плохо потрясают своей глубиной! "Потому что его читать перед сном плохо".
не совсем так, на какие только ухищрения не идут упоротые, что бы не налаживать нормального межпроцессного взаимодействия, применение XML внутри системы- это ... вобщем нет слов.

#3. gaal

Luca написал:
Спустя 20 лет до линуксоидов только стало доходить, что писать программы, которые парсят скрипты, которые парсят конфиги -- дурацкая идея.


XML надо также распарсить. Сюрприз.

#4. MOP3E

gaal написал:
XML надо также распарсить. Сюрприз.

Что мешает сделать стандартный парсер?

#5. beep

MOP3E написал:
Что мешает сделать стандартный парсер?

over9000 дистрибутивов, где прийдется пилить под каждый или делать форк под даный дистрибутив

#6. gaal

MOP3E написал:
Что мешает сделать стандартный парсер?


XML на эту роль плохо годится. Он избыточен. http://ru.wikipedia.org/wiki/XML

#7. gaal

beep написал:
over9000 дистрибутивов, где прийдется пилить под каждый или делать форк под даный дистрибутив


Формат конфига от дистра не меняется :) Если только не разработано под дистр.

#8. terenty79

У них всё время какие нибудь предложения. Недавно один предлОгал звуковой модуль переписатЪ, сейчас вот сеть. а сколько пены выделяется до сих пор, во время терок по темам, чего с иксами делать, или же чего вместо них. это система для необременяемых жизнью ботанов, но иногда в их среде появляются ну просто особенно уникальные индивидумы, со своими раз-предложениями.
Luca написал:
программы, которые парсят скрипты

Это любопытно. smile
Luca написал:
которые парсят конфиги -- дурацкая идея.

То ли дело - парсить реестр! Талантливо, элегантно!

Luca написал:
Аргументы почему XML - это плохо потрясают своей глубиной!

А почему Microsoft до сих пор не переведет реестр в XML?

terenty79 написал:
это система для необременяемых жизнью ботанов

По рифам побросало?

#10. pavel2403

pavel2403
Павел написал:
То ли дело - парсить реестр! Талантливо, элегантно!
Внезапно, реестр не парсят, Ламер детектед. Реестр иерархическая БД и время доступа к записи в БД в разы быстрее чем в любом конфиге, даже самом продвинутом и структурированном.

#11. selenscy

Хы-хы! Паша!

"База сама по себе сплошной скрипт" (с) AleksK

biggrin biggrin biggrin

У пенгванутых всёж на шкриптах!!!

#12. MOP3E

beep написал:
over9000 дистрибутивов, где прийдется пилить под каждый или делать форк под даный дистрибутив

Зачем? Сделать стандартный механизм сериализации/десериализации как в .Net или вообще сразу взять его из Mono - он там уже готовый. Мы ведь делаем общий для всех дистрибутивов сетевой стек, а не какую-то индивидуальную приблуду.

gaal написал:
XML на эту роль плохо годится. Он избыточен.

Твоя башка на эту роль плохо годится. XML создавался специально как язык разметки, максимально удобный для парсинга.

Павел написал:
То ли дело - парсить реестр! Талантливо, элегантно!

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

Павел написал:
А почему Microsoft до сих пор не переведет реестр в XML?

"Не сломалось - не чини".

#13. petrun

У нас категорически разное предствление о радикальности. Радикальные изменения в работе сети это передача ip пакетов через летеющие блюдца с Тральфамадора.
А это просто система конфигураци. Не все-ли равно какая она там?

#14. gaal

2 MOP3E

Скольков раз уже в этом убеждался. Дурак ты

Размер XML-документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз). Размер XML-документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например JSON [4] , YAML, Protocol Buffers) и особенно в форматах данных, оптимизированных для конкретного свлучая использования. Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных. XML содержит метаданные (об именах полей, классов, вложенности структур), и одновременно XML позиционируется как язык взаимодействия открытых систем. При передаче между системами большого количества объектов одного типа (одной структуры), передавать метаданные повторно нет смысла, хотя они содержатся в каждом экземпляре XML описания. Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения. [9]

#15. DonDublon3

gaal написал:
Размер XML-документа существенно больше бинарного представления тех же данных.

Поэтому не надо хранить в них большие объемы. А для конфигов - самое то.

#16. MOP3E

gaal написал:
Скольков раз уже в этом убеждался. Дурак ты

Размер XML-документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз). Размер XML-документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например JSON [4] , YAML, Protocol Buffers) и особенно в форматах данных, оптимизированных для конкретного свлучая использования. Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных. XML содержит метаданные (об именах полей, классов, вложенности структур), и одновременно XML позиционируется как язык взаимодействия открытых систем. При передаче между системами большого количества объектов одного типа (одной структуры), передавать метаданные повторно нет смысла, хотя они содержатся в каждом экземпляре XML описания.

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

gaal написал:
Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения.

Конечно-конечно, больной! В линухе уже всё это используется! Так классно используется, что хакеры мечтают о переходе на XML!

Если я дурак, то ты вообще даун. Кидаешь сюда копипасты из педевикии с таким видом, как будто это откровения святых. biggrin

#17. KaeSkat

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

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

#18. gaal

2 MOP3E

Попробуй их все скорректировать руками, когда/если потребуется :)

Тот же JSON на эту роль подходит гораздо лучше. Есть и готовое схожее решение. http://www.hyperrealm.com/libconfig/ Гораздо лучше всяких XML для настроек

http://habrahabr.ru/post/148948/

Цитата:
Как-то находясь в поиске как мне прикрутить конфигурационные ini файлы или json к моему сервачку перебирал варианты, но почему-то они были неудобны или слишком простые, или велосипеды. И хоть я люблю xml конфигурирование, но порою это чрезмерно огромные файлы и неудобно для небольшого количества настроек писать много текста. Раз задал другу вопрос по этой теме, он то мне и подкинул библиотеку. Напоминает она json в смеси с yaml.

#19. gaal

XML и JSON для сравнения

{
"firstName": "Иван",
"lastName": "Иванов",
"address": {
"streetAddress": "Московское ш., 101, кв.101",
"city": "Ленинград",
"postalCode": 101101
},
"phoneNumbers": [
"812 123-1234",
"916 123-4567"
]
}

<person>
<firstName>Иван</firstName>
<lastName>Иванов</lastName>
<address>
<streetAddress>Московское ш., 101, кв.101</streetAddress>
<city>Ленинград</city>
<postalCode>101101</postalCode>
</address>
<phoneNumbers>
<phoneNumber>812 123-1234</phoneNumber>
<phoneNumber>916 123-4567</phoneNumber>
</phoneNumbers>
</person>

<person firstName="Иван" lastName="Иванов">
<address streetAddress="Московское ш., 101, кв.101" city="Ленинград" postalCode="101101" />
<phoneNumbers>
<phoneNumber>812 123-1234</phoneNumber>
<phoneNumber>916 123-4567</phoneNumber>
</phoneNumbers>
</person>

#20. MOP3E

gaal написал:
Попробуй их все скорректировать руками, когда/если потребуется :)

Если требуется руками, значит программа - г№вно.

gaal написал:
Тот же JSON на эту роль подходит гораздо лучше.

Чем лучше?

gaal написал:
XML и JSON для сравнения

Смотри не обкакайся.
gaal написал:
{
"firstName": "Иван",
"lastName": "Иванов",
"address": {
"streetAddress": "Московское ш., 101, кв.101",
"city": "Ленинград",
"postalCode": 101101
},
"phoneNumbers": [
"812 123-1234",
"916 123-4567"
]
}

<person>
<firstName>Иван</firstName>
<lastName>Иванов</lastName>
<address>
<streetAddress>Московское ш., 101, кв.101</streetAddress>
<city>Ленинград</city>
<postalCode>101101</postalCode>
</address>
<phoneNumbers>
<phoneNumber>812 123-1234</phoneNumber>
<phoneNumber>916 123-4567</phoneNumber>
</phoneNumbers>
</person>

<person firstName="Иван" lastName="Иванов">
<address streetAddress="Московское ш., 101, кв.101" city="Ленинград" postalCode="101101" />
<phoneNumbers>
<phoneNumber>812 123-1234</phoneNumber>
<phoneNumber>916 123-4567</phoneNumber>
</phoneNumbers>
</person>


Браво!Киса,вы как всегда удивляете.Мы тут канешь все леди и джентльмены и все безоговорочно поняли вашу мысль и такое тоже можем только нужное в Google откроем и скопируем. +100500up

#22. pavel2403

pavel2403
gaal написал:
Попробуй их все скорректировать руками, когда/если потребуется :)

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

#23. MOP3E

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

В .Net прекрасный стандартный парсер. Сериализация объекта на диск занимает три строки кода. Десериализация - тоже.

#24. beep

MOP3E написал:
Зачем? Сделать стандартный механизм сериализации/десериализации как в .Net или вообще сразу взять его из Mono - он там уже готовый. Мы ведь делаем общий для всех дистрибутивов сетевой стек, а не какую-то индивидуальную приблуду.


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

#25. pavel2403

pavel2403
beep написал:
Сериализация объекта на диск занимает три строки кода. Десериализация - тоже.
причем здесь десериализация, если у тебя есть файл произвольной структуры и поправить надо именно внутри файла, что ты собрался сериализовывать, если тебе еще интерфейс только предстоит создать, ты его не знаешь, врубился??? В данной ситуации никакой парсер тебе не поможет, интерфейс все равно писать надо, и количество строчек кода может быть горазо больше 3-х. Так понятно?

#26. gaal

Само по себне предложение хорошее. Только лучше обезжиренный JSON или подобный формат.

#27. beep

pavel2403, surpriseбля буду но такого не писал

#28. pavel2403

pavel2403
beep написал:
бля буду но такого не писал
Извини, брат, это опять ГЛЮК, :( это конечно же для Морзе я писАл. :)

#29. pavel2403

pavel2403
gaal написал:
Только лучше обезжиренный JSON или подобный формат
Мне больше по душе CSV в нем можно одновременно реализовать как возможности записи в виде таблиц так и иерархии и он очень удобен для человеческого восприятия, и там нет ничего лишнего, никаких тегов, хотя и их при желании можно туда запихнуть если есть такая необходимость.

#30. Павел

pavel2403 написал:
Внезапно, реестр не парсят, Ламер детектед.

Да ладно, детектор! А что Windows делает с файлами реестра? Глотает как одно целое?
pavel2403 написал:
Реестр иерархическая БД

В этом смысле каталог с конфигами в любой иерархической файловой системе можно также рассматривать с позиций иерархической модели данных. И даже сетевой, если есть софтлинки. А в UNIX'ах они есть. Есть они и в Windows, только это как у пингвина крылья. wink

pavel2403 написал:
и время доступа к записи в БД в разы быстрее чем в любом конфиге, даже самом продвинутом и структурированном.

Это да. Если бы только все конфиги в Линуксе были в одном файле. Но нет.
Есть /etc, в которой лежат, как правило, коротенькие файлы. Их можно изменять. Их можно копировать. Их можно править на "холодном" диске. Если нужно, любая программа посмотрит конфиг у любой другой программы. Все преимущества реестра легко реализуются через стандартные операции с каталогами и файлами в Линуксе. А вот в плане доступности реестр очень плох.
MOP3E написал:
Реестр - это база данных, средства для работы с которой входтят в состав API Windows и едины для всех программ, работающих под управлением этой ОС. Текстовые конфиги в линухе штука настолько индивидуальная, что один и тот же конфиг может абсолютно по разному парситься в разных дистрибутивах линуха.

Ну, во-первых, Windows не ушла от текстовых конфигов. Поищите-ка *.ini в каталоге Windows. Ну ладно, system.ini и win.ini - это забота о приложениях Win16. А вот как понимать C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_perf.ini? Само имя этого файла - оксюморон. Навроде C:\Windows\himem2012.sys (совпадение случайно) biggrin
А есть еще *.inf...

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

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

Здесь согласен.

Вообще, что касается XML.
Можно быть против, можно быть за. Но объективно это уже пришло. Вот мы тут про иерархическую модель. А есть, например, такая статья еще 1999 года:

A Formal Data Model and Algebra for XML
Авторы:
David Beech (Oracle) dbeech@us.oracle.com
Ashok Malhotra (IBM) petsa@us.ibm.com
Michael Rys (Microsoft) mrys@microsoft.com

Обращаю внимание на домены в адресах.
Делалось это всё для СУБД. И было сделано. Сейчас СУБД каждой из этих компаний содержат 2 движка: реляционный и XML.
Применение XML в конфигах операционных систем в полной мере себя проявит, когда систем много. Причем не только серверов, но и десктопов. Это и задачи инвентаризации, и задачи автоматической настройки. IMHO.

#31. pavel2403

pavel2403
Павел написал:
В этом смысле каталог с конфигами в любой иерархической файловой системе можно также рассматривать с позиций иерархической модели данных.
Ага и пирамидка Рубика тоже, дальше что?
Павел написал:
Есть /etc, в которой лежат, как правило, коротенькие файлы. Их можно изменять. Их можно копировать. Их можно править на "холодном" диске. Если нужно, любая программа посмотрит конфиг у любой другой программы.
Внезапно, получить запись в БД все равно будет быстрее чем найти даже самый короткий файл, открыть его, и распарсить. Что касается доступа к настройкам одной программы из другой, то непонятно, чем реестр тебе не угодил? Там так же все это просто извлекается, сюрпрйз?
Павел написал:
Все преимущества реестра легко реализуются через стандартные операции с каталогами и файлами в Линуксе
Да ты что, неужели??? Ну реализуй, а мы посмотрим, что у тебя получиться, посмеёмся. Еще раз для тупых аналогичность структуры каких-то моделей еще не значит их полную идеинтичность по параметрам, пример с пирамидкой смотри выше. то бы было доступно уже набивший аскомину пример с авто: мерседес 600 и камаз 4310, 4 колеса, руль, трансмиссия, подвеска, все аналогично, вот только грузы весом в несколько тонн почему то возят на камазах, а не на мерседесах.
Павел написал:
А вот в плане доступности реестр очень плох.
Чем плох и кому плох? Тебе? так это ни о чем. Мне например в самый раз. А плох он для тебя тем, что значения там храняться не только в текстовом формате и тебе трудно туда залезть своими кривыми лапками и что-то поправить,да? Так это специально так сделано, что бы доступ был по возможности только через специальные функции, потому как правильные значения этих ключей весьма критичны для работы ОС.
Павел написал:
Ну, во-первых, Windows не ушла от текстовых конфигов
Ну и что? Обратная совместимость она такая совместимость, кторой в Линухе к слову просто не существует, а в виде, благодаря поддержке конфигов на уровне API старый софт работает так же успешно как и новый. Дошло почему так?
Павел написал:
не будем забывать про то, что ветви реестра - это отдельные объекты доступа, и они требуют отдельных привилегий.
Это так, но разве это плохо? А в твоей любимой файловой системе разве не так? Разве файл или каталог не может быть отдельным объектом доступа с со своими специфичными правами? НИОЧЕМ.
Павел написал:
Вот уж, воистину, "не плоди сущности без необходимости"!
Действительно, гораздо проще держать все настройки в одном месте чем они буду размазаны по всей системе, где меньше сущностей в 3-х файлах реестра или в 100500 конфигах?

#32. MOP3E

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

Что мешает разработчику спроектировать объект до того, как начнётся кодинг? Естественно, до начала проектирования никто ничего не знает, но на то оно и проектирование, чтобы дать ответы на 99% вопросов до начала кодинга. Что касается парсера XML, то он уже есть готовый. В Mono.

pavel2403 написал:
Мне больше по душе CSV в нем можно одновременно реализовать как возможности записи в виде таблиц так и иерархии и он очень удобен для человеческого восприятия, и там нет ничего лишнего, никаких тегов, хотя и их при желании можно туда запихнуть если есть такая необходимость.

Да уж, там вообще нет НИЧЕГО. Обычная безличная табличка.

Павел написал:
Ну, во-первых, Windows не ушла от текстовых конфигов. Поищите-ка *.ini в каталоге Windows. Ну ладно, system.ini и win.ini - это забота о приложениях Win16. А вот как понимать C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_perf.ini? Само имя этого файла - оксюморон. Навроде C:\Windows\himem2012.sys (совпадение случайно) biggrin
А есть еще *.inf...

Во-первых, наследство и механизмы совместимости.
Во-вторых, *.inf - это база данных драйверов. Когда драйвер устанавливается в систему, эти данные копируются в реестр, но зачем там данные обо ВСЕХ драйверах? Кстати, в файлах *.ini .Net тоже какая-то информация о драйверах прописана.
В третьих, himem2012.sys - не нашёл вообще в папке Windows.
И, наконец, в четвёртых - все эти файлы построены одинаково и в API Windows (ВНЕЗАПНО!) есть стандартные функции для их создания и парсинга. В отличие от разброда и шатания линуховых конфигов.

Павел написал:
Во-вторых, к вопросу о единообразии: не будем забывать про то, что ветви реестра - это отдельные объекты доступа, и они требуют отдельных привилегий.

Скажи, в линухе любая программа может затереть или перезаписать данные в конфиге любой другой программы? Если может - это действительно здорово! Такие возможности для вирусов открываются...

#33. gaal

MOP3E написал:
Скажи, в линухе любая программа может затереть или перезаписать данные в конфиге любой другой программы? Если может - это действительно здорово! Такие возможности для вирусов открываются...
Фантазер :) Нет, не может, если нет прав доступа.

#34. selenscy

Хы-хы! Морзе молодец! Подье....л пенгванутых smile

gaal написал:
Фантазер :) Нет, не может, если нет прав доступа.


А в вин всё не так значит? wink

#35. Павел

pavel2403 написал:
Ага и пирамидка Рубика тоже, дальше что?


Дальше - не надо заявлять, что поиск в реестре более оптимален.
pavel2403 написал:
Внезапно, получить запись в БД все равно будет быстрее чем найти даже самый короткий файл, открыть его, и распарсить.

Пруф - в студию.

pavel2403 написал:
Павел написал:
Все преимущества реестра легко реализуются через стандартные операции с каталогами и файлами в Линуксе

Да ты что, неужели??? Ну реализуй, а мы посмотрим, что у тебя получиться, посмеёмся.

До меня уже успели. Начинай смеяться.

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


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

pavel2403 написал:
А вот в плане доступности реестр очень плох.

Чем плох и кому плох? Тебе? так это ни о чем. Мне например в самый раз.


Ну, разумеется. Когда у Тети Зины падает реестр, она зовет таких, как ты. Так сокровенное знание о папке System Volume information поддерживает ЧСВ на должном уровне.

pavel2403 написал:
благодаря поддержке конфигов на уровне API старый софт работает так же успешно как и новый. Дошло почему так?

Угу. Потому что приложения для .NET - это старый софт. Не?
MOP3E написал:
Кстати, в файлах *.ini .Net тоже какая-то информация о драйверах прописана.

Это все не объясняет парадокса существования в системной папке файла aspnet_perf.ini в 2012 году.

pavel2403 написал:
гораздо проще держать все настройки в одном месте чем они буду размазаны по всей системе, где меньше сущностей в 3-х файлах реестра или в 100500 конфигах?

Все настройки лучше держать в единственном каталоге /etc. Ну, можно еще и в /boot. biggrin

#36. selenscy

Павел написал:
Все настройки лучше держать в единственном каталоге /etc. Ну, можно еще и в /boot. biggrin


Хи-хи-хи! И настройки пользователя чо уж там, ага!

#37. MOP3E

gaal написал:
Фантазер :) Нет, не может, если нет прав доступа.

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

???

#38. MOP3E

Павел написал:
Это все не объясняет парадокса существования в системной папке файла aspnet_perf.ini в 2012 году.

И что с того?

#39. MOP3E

Павел написал:
Угу. Потому что приложения для .NET - это старый софт. Не?

ASP - очень старая технология.

#40. KaeSkat

Павел написал:
Это все не объясняет парадокса существования в системной папке файла aspnet_perf.ini в 2012 году.

Между прочим, ini-файлы, так же как и .h в каталогах .NET - всего лишь комплект ресурсов, которые подтягиваются при нужных обработках. А вовсе не изменяемые параметры софта, которые следует хранить в реестре. Так что учите матчасть - в 2012 году в *.ini файлах совсем не обязательно хранят настройки.

#41. jimm

Друзья, преимущества xml либо json совсем не в размерах хранимых данных.
json удобен для передачи объектов в браузер, например обычным eval('{name:"Vasya"}'); получим готовый к использованию js-объект.
В xml вы забыли упомянуть такую прекрасную штуку, как xsd-схемы валидации. Вот этого явно не помешало бы в линуксе - стандартизировать данные и xsd-схемы в этом незаменимы.
Далее, для чтения xml есть масса утилит, представляющих xml-докумиент в виде дерева объектов. .Net все конфиги хранит в xml, начиная с machine.config, заканчивая любой локальной директорией. А у json-a немного другие задачи ;)

#42. volia

Очень все интересно )) статья очень понравилась…. Всё интересно и изложено доступно и увлекательно. Спасибо!