Разработчики openSUSE представили (http://lizards.opensuse.org/2011/11/07/webyast-0-3-is-out/) новый релиз проекта WebYaST (http://en.opensuse.org/Portal:WebYaST), в рамках которого развивается web-интерфейс для удаленного администрирования системы, изначально разработанный для SLES. Используя WebYaST пользователь получает возможность настройки и обслуживания сервера, виртуального окружения или рабочей станции с любой машины, имеющей web-браузер. Проект написан (https://github.com/webyast/webyast) на Ruby on Rails и доступен (https://build.opensuse.org/project/show?project=YaST%3A...) в пакетах для выпусков openSUSE 11.4 и 12.1-rc.<center><a href="http://lizards.opensuse.org/wp-content/uploads/2011/11/WebYa... src="http://www.opennet.me/opennews/pics_base/32249_1320736759.png " style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Среди возможностей (http://en.opensuse.org/WebYaST_Project_Details...URL: http://lizards.opensuse.org/2011/11/07/webyast-0-3-is-out/
Новость: http://www.opennet.me/opennews/art.shtml?num=32249
Не пойму зачем писать на Ruby on Rails, это дополнительные зависимости.
Чем python + django хуже? Уже установлен. В конце концов python больше подходит под системное администрирование, одних библиотек черт знает сколько.
Каждый пишет на чем ему удобнее.
Какая разница, на чем оно написано? Чем так страшны дополнительные зависимости?
ror много памяти жрёт
Ага, а питон не жрёт, да?
потенциальная реализация обсуждаемого приложения на python/flask, например - да, меньше
Питон и тормозит дичайше, ибо галимый интерпретатор. И памяти жрет много. А потенциальная реализация - ну знаете ли. Пусть вам потенциально заплатят за работу, чтоли :)
в контексте обсуждения ruby и ror, все ваши посылы - пустой звук, по всем перечисленным вами параметрам (скорость, потребление памяти) python 2.7.x уделывает ruby 1.9.x. гуглите тесты
> Какая разница, на чем оно написано? Чем так страшны дополнительные зависимости?Утрируя: будете ли вы делать UI для ограниченного в ресурсах embedded-устройства на базе монструозного KDE4? Или все-таки выберете что-нибудь покомпактнее?
> Утрируя: будете ли вы делать UI для ограниченного в ресурсах embedded-устройства на
> базе монструозного KDE4? Или все-таки выберете что-нибудь покомпактнее?К питону это не относится: это тормозное уе...во в эмбеддовке жесточайше тормозит и норовит схавать всю память.
> Чем python + django хуже? Уже установлен.Что-то не вижу у меня в системе django.
По собственному опыту, Яст создает больше проблем, чем решает: конфигурация системы усложнена, менее прозрачна (целевые конфигурационные файлы генерируются из каких-то еще). То, что в других дистрибутивах просто работает, в Сусе требует копания в Ясте (например, установка какого-нибудь железа). Сама идеология чем-то напоминает Виндоус.
Где вы в винде видели ТЕКСТОВЫЙ конфигуратор железа?
Дело ведь не в том, есть ли в конфигураторе псевдографический режим интерфейса. Сам интерфейс излишне многословен, в стиле Виндоус.
Простите, а в каком месте напоминает?
> Простите, а в каком месте напоминает?Излишне многословен, требует к себе внимания, когда нужно быть незаметным (пример с конфигурацией оборудования), усложняет непосредственную работу с файлами конфигурации, т. к. они генерируются из каких-то еще.
>> Простите, а в каком месте напоминает?
> Излишне многословен, требует к себе внимания, когда нужно быть незаметным (пример с
> конфигурацией оборудования), усложняет непосредственную работу с файлами конфигурации,
> т. к. они генерируются из каких-то еще.Трололо. Примеры в студию.
Вот и правильно.
Привычнее для большинства
> По собственному опыту, Яст создает больше проблем, чем решаетДа, использование микроскоп вместо молотка при забивании гвоздей создает больше проблем, чем решает.
> Сама идеология чем-то напоминает Виндоус.Идеология винды - это первичность гуя, что автоматически ограничивает возможности настройки мышкокликаньем. С другой стороны, в рассматриваемом случае, ситуация строго обратна - и веб-морда, и гуй, и псевдографика являются лишь фронтендами. Если они вам не нравятся - пожалуйста, используйте обычные конфиги, они первичны.
Проблема в том, что настоящие конфиги генерируются из других конфигов. Излишнее усложнение, нужно запускать SuSEconfig после каждого изменения и ждать непонятно чего. Если я изменю что-то непосредственно в целевом конфиге, потому что возможностей файлов конфигурации Сусе оказалось недостаточно, мои изменения перепишутся при следующем выполнении SuSEconfig. Зачем все эти сложности? Это нифига не Юникс вей.
> По собственному опыту, Яст создает больше проблем, чем решает: конфигурация системы усложнена,
> менее прозрачна (целевые конфигурационные файлы генерируются из каких-то еще). То, что
> в других дистрибутивах просто работает, в Сусе требует копания в Ясте
> (например, установка какого-нибудь железа). Сама идеология чем-то напоминает Виндоус.неслыханная некомпетентность в сочетании с железобетонной категоричностью
>>Сама идеология чем-то напоминает ВиндоусИ правильно делает.
В сабже еще нужна поддержка работы с группой компьютеров одновременно, но если сервер работает на каждом отдельном ПК, это го не добиться. Лучше бы сабж ставился на комп администратора, и подключался к клиентам по тому же ssh
google://System+Configuration+Management
Странно, что Вы об этом не знаете, если действительно управляете множеством серверов.
по крайней мере конфиги в /etc/sysconfig прекрасно документированы:)
Реестр Windows тоже, но не из коробки. Но он и так интуитивно понятен.
Афигенная у вас интуиция!
Обьясните мне что значит HKEY_CURRENT_CONFIG/System/CurrentControlSet/Control/VIDEO/{0B4A9C58-7626-41CB-84D2-E001294695D2}/0000/DefaultSettings.Flags=0
А то меня бог интуицией не наградил...
В разделе действующих настроек можно задать настроку № "0000" COM-объекта с GUID {....}, содержание настройки - значение флага по умолчанию, равно 0. Данный COM-объект является компонентом драйвера видеоадаптера или подсистемы видеовывода.Другое дело, что COM-объекты в Windows не настраиваются через реестр, и ИЛИ имеют GUI, ИЛИ не требуют ручной настройки.
> В разделе действующих настроек можно задать настроку № "0000" COM-объекта с GUID
> {....}, содержание настройки - значение флага по умолчанию, равно 0. Данный
> COM-объект является компонентом драйвера видеоадаптера или подсистемы видеовывода.
> Другое дело, что COM-объекты в Windows не настраиваются через реестр, и ИЛИ
> имеют GUI, ИЛИ не требуют ручной настройки.Емкий ответ. Абсолютно все понятно что ничего не понятно...
Вы описали мне структуру реестра но не дали отчета на то что хранится в данной ячейке реестра. Видать информация хранимая там интуитивно понятна...
Хммм, возможно (тонко намекаю) это вы привели некорректный пример.Если бы вы взяли напр. HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\CurrentTheme="мой_путь\custom.theme", то и ответ был бы иным. Но вы выбрали один из сотен технических COM-объектов, настройки которых пользователем не настраиваются, хотя он и может их посмотреть.
> Хммм, возможно (тонко намекаю) это вы привели некорректный пример.
> Если бы вы взяли напр. HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\CurrentTheme="мой_путь\custom.theme",
> то и ответ был бы иным. Но вы выбрали один из
> сотен технических COM-объектов, настройки которых пользователем не настраиваются, хотя
> он и может их посмотреть.Тогда я б сказал бы так:
Иногда реестр Виндовс частично может быть интуитивно понятен.Даже Ваш пример указывает на то что какая-то тема в Виндовс = кастом.тема. Но предположение что это тема Десктопа или тема логина или прочая какая тема Виндовс - это только интуитивное предположение не дающее 100процентного ответа.
И такие "интуитивные" ячейки не есть основная процентная масса реестра. Мало того абсолютно неизвестно какие значения оно может или должно принимать...
Возможно (тонко намекаю) такой "формат" (моднявое слово :-)) реестра была сделан чтобы дать продвинутым (очень продвинутым) пользователям возможность настройки всех настраиваемых параметров, но основные из них были вынесены в GUI формы и настраиваются с использованием средств графического интерфейса.Сравните с "форматом" Linux, где текстовый файл конфигурации является первичным и настраивается именно он, а графическая оболочка настройки обычно притянута "за уши" и занимается парсировкой текстового файла вместо работы со структурированным хранилищем. В Windows, начиная с Win98, ini-файлы не рекомендуются к использованию, а с Vista работа с ними, если программа была установлена в Program files, затруднена.
Как показывает практика, "структурированное хранилище" создает больше проблем, чем решает.
Чем проще формат хранения данных - тем меньше возможностей устроить беспричинную путаницу.
А гибкость текстовых конфигов вполне достаточна для абсолютного большинства задач.
Для большинства, кроме задачи эффективного использования вычислительных ресурсов. Хотите опровергнуть - объясните почему SQL базы не хранятся в текстовых документах?
> объясните почему SQL базы не хранятся в текстовых документах?сначала объясните, почему реестр не хранится на raw разделе.
Не по теме, но отвечу: системный (raw) раздел используется на этапе загрузки компьютера, реестр используется постоянно, как на этапе загрузки, так и во время работы.
> Не по теме, но отвечу: системный (raw) раздел используется на этапе загрузкине по теме не нужно. нужно ответить почему базы данных лежат на raw разделах, а реестр - нет.
> Не по теме, но отвечу: системный (raw) раздел используется на этапе загрузки
> компьютераПохоже, вы вообще не понимаете, что такое raw-разделы и как их используют.
В терминологии Windows, "системным (raw)" разделом называют 100 Мб неименованный раздел, на котором ОС хранит необходимые для загрузки системные файлы и драйвера.Размер реестра не превышает 200 кб, и оперировать терминологией и решениям БД считаю неверным.
Похоже, это вы не понимаете о чём идёт речь и, как женщина, ставите целью не поиск истины, а трёп ради трёпа и локальные победы. Только сегодня ехал, час слушал их болтовню:
1: Я нашла парикмахера. Она очень хорошая.
2: Но она дорогая.
1: Всё хорошее дорого (локальная победа!)
2: Для меня это дорого.
1: Для меня тоже, завтра иду к дешёвому мастеру (локальная победа!)
> Размер реестра не превышает 200 кб, и оперировать терминологией и решениям БД считаю неверным."размер текстового файла конфигурации..." и далее по тексту. это не говоря о том, что вас никто не заставлял начинать рассуждать про БД и прочие вещи, о которых вы имеете весьма приблизительное представление.
в терминологии microsoft, raw разделом называют ровно то, что им и является.
http://msdn.microsoft.com/en-us/library/aa933078%28v=sq...
системный и загрузочный разделы, в той же терминологии, так и называются - system partitions and boot partitions, либо system volume and boot volume.
http://support.microsoft.com/kb/314470
Системный раздел = system partition. Системный (raw) раздел = для обозначения системного 100 Мб раздела в некоторых документах термины raw и system partition используются совместно, raw как показатель неименованности и невозможности непосредственного доступа. Гугл здесь не поможет, за 5 минут профи не станешь.> рассуждать про БД и прочие вещи, о которых вы имеете весьма приблизительное представление.
Смачно поржали.
> в некоторых документах термины raw и system partition
> используются совместно, raw как показатель неименованности и невозможности непосредственного
> доступа. Гугл здесь не поможет, за 5 минут профи не станешь."смачно поржал" (c). где можно увидеть эти секретные документы ? где вообще можно увидеть хоть один документ от microsoft, в котором раздел с файловой системой (любой, которую официально поддерживает microsoft) называют raw разделом ? и да, гугл ответить не поможет, за 5 минут профи не станешь.
> Хотите опровергнуть - объясните почему SQL базы не хранятся в текстовых документах?Похоже, логика в вашей голове не ночевала.
Ему про конфиги - он про SQL.
> Хммм, возможно (тонко намекаю) это вы привели некорректный пример.Скорее, некорректно утверждение про интуитивную понятность реестра.
По сравнению с текстовым конфигурационным файлом иерархическое хранилище проще и понятнее. Сравните с файловой системой: в одной есть файлы (ключи реестра) и папки, в другой - папки только на первом уровне (много конфигурационных файлов, в каждом много ключей).Заметьте, я намерено избегаю упоминаний "Win" и "Lin". Не важно какая ОС, важна эффективность решения.
> По сравнению с текстовым конфигурационным файлом иерархическое хранилище проще и понятнее.Текстовый конфигурационный файл некорректно сравнивать с иерархическим хранилищем. Его корректно сравнивать с бинарным конфигурационным файлом. А по сравнению с конфигурационным файлом, для просмотра и изменения которого требуется специализированное ПО (например, regedit), текстовый конфигурационный файл проще и понятнее. Кстати, в юникс-подобных системах текстовые конфигурационные файлы как раз и хранятся в иерархическом хранилище — то бишь в каталоге /etc, его подкаталогах и подкаталогах подкаталогов ad infinitum.
1. реестр - это API, фактически реестр может хранится где и как угодно, и для приложений любые изменения будут незаметны. Даже regedit пользуется тем же API, что и все остальные. Сравним гибкость решения с решением хранить всё в текстовиках.2. что происходит чаще (и насколько чаще): чтение параметра программой или просмотр/изменение параметра пользователем? Следовательно какую из двух операций разработчики ОС должны стремиться ускорить и упростить до предела? Разумеется, мы рассматриваем ситуацию что любое ПО настраивается один раз и работает 3-5 лет.
3. мы сравниваем не типы файлов, а различные решения по хранению параметров ОС и ПО.
> 1. реестр - это API, фактически реестр может хранится где и как
> угодно, и для приложений любые изменения будут незаметны. Даже regedit пользуется
> тем же API, что и все остальные. Сравним гибкость решения с
> решением хранить всё в текстовиках.В текстовиках гораздо гибче! Почему?
1) Текстовики и примеры конфигурации гораздо лучше гуглятся.
2) Я могу редактировать текстовик любой удобной мне программой, а не убогим регэдитом.
3) Я могу например делать продвинутый поиск. В регэдите нельзя даже просто найти ключ который содержит одно но не содержит другое. Поэтому когда оказывается что нечто входит в реестр в чуть более чем 9000 экземплярах - я не могу уточнить поисковый запрос дабы получить более вменяемое число результатов. С другой стороны, grep прекрасно пайпается в любую иную утилиту. Дешево и сердито. Регэдиту до такой гибкости как пехом до пекина.> 2. что происходит чаще (и насколько чаще): чтение параметра программой или просмотр/изменение
> параметра пользователем?Чаще конечно программой, но кого это волнует? Меня как пользователя волнует мое удобство. Пользоваться абсолютно уродским регедитом, при отсутствии примеров и документации на то что и как под рукой - ни разу не удобно.
Например, я могу найти простейший конфиг для нжинкса за 2 минуты гуглем. Он будет делать на 90% что мне надо. За еще 2 минуты я его исправлю чтобы он делал именно то что надо мне с уже 100% точностью. И все, можно запускать сервер. Будет работать. А теперь пробуем повторить то же самое для IIS и офигеем когда ничего подобного и близко не получится.
> Следовательно какую из двух операций разработчики ОС должны стремиться
> ускорить и упростить до предела? Разумеется, мы рассматриваем ситуацию что любое
> ПО настраивается один раз и работает 3-5 лет.Железу то похрен, а вот человеку приходится мучаться. Мучения человека - приоритетнее мучений железа, имхо. Админ тоже человек, и о его удобстве тоже хорошо бы немного подумать. Заставлять админа делать всю продвинутую конфигурацию системы через одну горбатую утилиту? Без шансов получить около параметра комментарий с примером его применения и описанием? (в дефолтных конфигах софта это просто хороший тон) Без нормального поиска? Да вы братцы явно не гуманисты, или просто поклонники Мазоха.
> 3. мы сравниваем не типы файлов, а различные решения по хранению параметров ОС и ПО.
Нормальная программа читает конфигурацию 1 раз, при старте. Какая мне разница, за 10 микросекунд или 20 она это сделает? И кстати да, в случае конфига программа может заметить что его изменили и перечитать. Есть даже более-менее устоявшийся псевдостандарт отсигналить демону что его просят перечитать конфиг, послав sighup (который по устоявшейся практике провоцирует "мягкий рестарт" - программа не стартует снова, но перечитывает конфиг заново и переоткрывает логи, что позволяет применять изменения конфигурации в момент и забирать логи в сторонку для архивного хранения и ротации не мешая программе). А если какой-то имбецил постоянно дергает чтение реестра, может быть, стоит задаться вопросом - а нафига б он это делает?
Вот поэтому у Windows 80%, а у Linux менее 3%.
> По сравнению с текстовым конфигурационным файлом иерархическое хранилище проще и понятнее.Не надо противопоставлять текстовый файл и иерархическое хранилище.
Если нужно, и из текстового файла можно сделать "простой и понятный" реестр - XML тому яркий пример.
Но для задач конфигурации обычно хватает одного, максимум двух уровней иерархии, что прекрасно организуется даже в формате INI. Все, что выше и сложнее - служит не повышению гибкости, но лишь запутыванию и усложнению структуры данных, что особенно хорошо видно при открытии программы regedit.
> особенно хорошо видно при открытии программы regedit.А еще видно что регедит - убогая фигня. Там даже поиска нормального нет!
А зачем нужен поиск? Если вы знаете ЧТО вы ищете, то вы знаете ГДЕ это искать.Примеры из реальной жизни: в каком магазине вы будете искать новую обувь? В продуктовом? В магазине игрушек? Может, их продают в химчистке? Если же вы быдло-админ - увольте-с, вас близко к реальной системе подпускать нельзя.
> Другое дело, что COM-объекты в Windows не настраиваются через реестр, и ИЛИ
> имеют GUI, ИЛИ не требуют ручной настройки.Ага, а куча параметров у SMB, NTDS, RPC, TCP/IP и еще over 9000 сервисов и дров, которые иногда все-таки требуют настройки и почему-то не настраиваются ни через какой GUI - это ничего так? А то что коды ошибок и параметры реестра искать - убиться можно и вообще ни разу не интуитивно - нормальненько? Например, часть параметров в реестре вообще не прописана (в отличие от конифга, там нельзя закоментить пример) и узнать о их наличии можно лишь обыскавшись на msdn или сторонних сайтах. Майкрософтовских студентов не учили что врать - нехорошо?
Слова "COM-объект" вам не знакомы или вы их принципиально игнорируете? TCP/IP по-вашему COM-объект? Или вы считаете что TCP/IP реализован в Windows через COM-объект? Если вы не знаете Windows, нам просто не о чем разговаривать, т.к. вы обсуждаете предметную область, которой не владеете.
> Реестр Windows тоже, но не из коробки. Но он и так интуитивно понятен.Да, конечно, это же интуитивно понятно, когда надо влезть на 10-й уровень вложенности и прописать драйверу параметр который там вообще отсутствует и который можно разве что нагуглить (встроенный поиск у мс традиционно неюзабелен) на немеряном мсдн-е :)
> по крайней мере конфиги в /etc/sysconfig прекрасно документированы:)/etc/sysconfig/* - жуткие костыли, если вдуматься.
http://www.0pointer.de/blog/projects/on-etc-sysinit
Выглядит неплохо в отличие от вебмин. =\
ajenti.org - Ajenti наше всё! На Python-е!
> ajenti.org - Ajenti наше всё! На Python-е!приходите сразу, как только авторы начнут поддерживать openSUSE, тогда и поговорим
хмм а контроллер домена через это поднять можно ?
