LINUX.ORG.RU

GNOME 2.6 Beta 2


0

0

Всего через несколько дней после первой беты среды GNOME, вышла Beta2. Удивительно, но за такое короткое время было исправлено очень много багов. Новые фичи касаются в основном пользовательского интерфейса программ - подгон его под GNOME HIG.

Скачать здесь: http://ftp.gnome.org/pub/GNOME/deskto...

>>> Подробности

anonymous

Проверено: svyatogor

Не знаю, пока не смотрел, думаю скоро появится в моем любимом Gentoo - тогда попробую. Вот что приходит в голову:

1. Если говорить о внешнем виде, то у гнома есть свой стиль, и достаточно привлекательный, да, кде красиво, но что-то не то.

2. Я слабо верю в надобность идеальной универсальной среды с интергацией приложений и пр. но меня откровенно радует то, что когда друзья - виндузятники отправляют мне какие-нибудь doc или excel файлы - я совершенно спокойно могу с ними работать в AbiWord и Gnumeric.

3. Не понятно почему гномовцы тратят силы на разработку собственных light-weight браузеров на движке мозиллы, когда есть firefox.

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

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

> 1. Если говорить о внешнем виде, то у гнома есть свой стиль, и 
> достаточно привлекательный, да, кде красиво, но что-то не то.

Как сказал кто-то в треде про бета1. ГНОМ прост и красив, как хороший меч. ;-/


> 2. Я слабо верю в надобность идеальной универсальной среды с 
>интергацией приложений и пр. но меня откровенно радует то, что когда 
>друзья - виндузятники отправляют мне какие-нибудь doc или excel файлы -
> я совершенно спокойно могу с ними работать в AbiWord и Gnumeric.

Кстати, а это правда, что Gnumeric с xls работает лучше, чем OOCalc? А то я себе поставил из debian sid какую-то версию - понравилось очень, но совместимость с форматами МС один из решающих факторов.


> 3. Не понятно почему гномовцы тратят силы на разработку собственных 
> light-weight браузеров на движке мозиллы, когда есть firefox.

Слышал про GNOME HIG? Так вот у firefox generic-интерфейс, не соотв. GNOME HIG (human interface guidelines). Кроме того - интеграция (теминг вместе со всем остальным, использование gconf, упрощение ембеддинга и т.д.), нормальная локализация, через gettext. Все таки GNOME - не просто набор программ, а десктопная среда, в которой все должно быть реюзабельно, выполнено в одном стиле и т.п.

> 4. Проект Gnome - прородитель массы классных библиотек, которые 
> могут быть использованы и вне Gnome. 

Это точно, хотя всякие чиста-крутые [censored], ненавидящее GNOME непонятно за что, увидев в аптгете зависимости от библиотек, в названии которых есть подстрока gnome сразу идут на лор кричать о дерьмовости программы. ;-[

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

> Как сказал кто-то в треде про бета1. ГНОМ прост и красив, как хороший > меч. ;-/

Скорее, как ржавый гвоздь.

> Кстати, а это правда, что Gnumeric с xls работает лучше, чем OOCalc?

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

> Так вот у firefox generic-интерфейс, не соотв. GNOME HIG (human > interface guidelines).

Нормальный у файрфокса интерфейс, ты мудак совсем что-ли?

> Кроме того - интеграция (теминг вместе со всем остальным)

Нахер не нужно

> использование gconf ГКонф это типа копия виндового реестра? Нафиг нафиг.

> упрощение ембеддинга и т.д.

Неуебок и так нормально проембедит, ты предлагаешь юзать тормозные гномовские либы для этого? Пипец.

> нормальная локализация, через gettext.

Какой еще гетекст? Нормальная у файрфокс локализация - скачал файл, поставил и готово. А тут еще геттекст какой-то надо.

> Все таки GNOME - не просто набор программ, а десктопная среда, в которой все должно быть реюзабельно, выполнено в одном стиле и т.п.

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

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

Работаю за многими машинами, самая мощная - P4 3.2HT, 2GB RAM. Самая слабая - ноутбук (p4-1.8 Mobile/256 Ram). Так вот на ноуте стоит ALT MASTER2.2 из "вчерашнего" сизифа и Icewm не слишком быстрее Gnome грузится и работает, чисто субъективно - Gnome страртует чуть мендленней, но потом работает _абсолютно_ без лагов. На П4 3.2 стоит Gentoo со всеми приложениями собранными из исходников, так там вообше разница не заметна, все просто летает - нажал, "чпок" и все, уже в проге.

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

> Кстати, а это правда, что Gnumeric с xls работает лучше, чем OOCalc?

Не знаю, сегодня в офис пришла дока (.doc файл из MS WORD) у начальника в ASP Linux в OpenOffice не открылась, у меня на Suse и Gentoo в AbiWord открывается без проблем.

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

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

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

> Кстати, а это правда, что Gnumeric с xls работает лучше, чем OOCalc?

Да, правда. И сохраняет он их лучше =) Вот только скриптов нормальных нет... А вот AbiWord к сожалению .doc'и понимает хуже, чем OOwriter.

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

В целом, Вам уже ответили. Я только хочу подробнее про браузеры.

Для гнома хороший браузерный движок - это пол-дела. Во-первых, нужно единство внешнего вида всего десктопа. Во-вторых, целостная и единая система конфигурирования. Например, чтобы настройки прокси были бы едиными для всего гнома (вряд ли огнелис лезет в gconf за настройками прокси, правда?). Далее, HIG в гноме - почти Библия. И диагноз "non-HIG-compliant" - смертный приговор. Соббсно, именно на этом погорел мой любимый галеон - хотя по остальным пунктам он был вполне пригоден. Лично я не одобряю выбор гномовцев, но у них есть четкое видение того, что они хотят от своего десктопа - и выбор они сделали на основании своих приоритетов. Огнелис - кроссплатформенная вестч, поэтому о глубинной интеграции в гном речи быть не может - поэтому даже не рассматривался как потенциальный браузер для гнома. Кстати, гном очень осторожен даже в выборе внешних библиотек - поэтому даже введение внешней зависимости от мозилловского движка (при включении Епифани) обсуждалось очень внимательно.

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

@LX >думаю скоро появится в моем любимом Gentoo - тогда попробую. тсссс...только никому не говори....хоть и неофициально, но он там уже есть ;-) hint: http://breakmygentoo.net

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

> Сам то понял что сказал? Каких ещё лагов?

(англ.) lag - запаздывание, отставание. Вроде delay.

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

>> Кстати, а это правда, что Gnumeric с xls работает лучше, чем OOCalc?

>Да, правда. И сохраняет он их лучше =)

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

>А вот AbiWord к сожалению .doc'и понимает хуже, чем OOwriter.

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

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

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

У гнумерика есть одно преимущество - нет ограничение на количество строк. А у OOcalc - 32578 и все. Тут кто-то ссылку давал на прайс cisco - так вот в OO он весь не лезет.

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

> А у OOcalc - 32578 и все

ух ты!!!! Так значит не только MSO может быть гавном:)

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

Гномом периодически интересуюсь, но если evo может и заменит kmail (кстати, надо посмотреть), то звоню я с помощью kppp. Но вот - действительно неприяность. Насколько помню, гномовская звонилка могла звонить только от рута.

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

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

Гномом периодически интересуюсь, но если evo может и заменит kmail (кстати, надо посмотреть), то звоню я с помощью kppp. Но вот - действительно неприяность. Насколько помню, гномовская звонилка могла звонить только от рута.

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

---------------

В Debian нужно добавить юзера в группу dip и все становится шоколадно, а вообще один чувак обещал к середине апреля сделать звонилку а-ля kppp, но под gtk, для gnome. Вот ссылка: http://www.rcub.bg.ac.yu/~bruce/gnome/gppp/

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

>Гномом периодически интересуюсь, но если evo может и заменит kmail (кстати, надо посмотреть), то звоню я с помощью kppp. Но вот - действительно неприяность. Насколько помню, гномовская звонилка могла звонить только от рута.

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

Открою страшную тайну: писать самому скрипты обычно не надо. Во первых, есть gnome system tools, в состав которых входит конфигуратор сети, в т.ч. и диалапа.

В RH и федоре есть свой конфигуратор сети и управление сетью, которые позволяют настраивать диалап и дозваниваться. Если диалап настроен, можно дозваниваться с помощью апплета "лампочки модема". В нем следует указать консольную команду для дозвона и для отсоединения. Т.о. дозвон выполняется одним щелчком в апплете (ну еще появляется окошко, где это надо подтвердить). Рут нужен только для настройки сети, дозвонка работает без него.

Но вообще, отсутствие полноценной звонилки проблемой считается, только руки до этого еще не дошли.

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

Да, по скригшотам, клон KPPP только на GTK Хотелось бы попробовать, должно получиться неплохо.

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

> Слышал про GNOME HIG?

If you can't make it good, make it look good. Вот к этому он и сводится.

> Так вот у firefox generic-интерфейс, не соотв. GNOME HIG (human interface guidelines).

Ага, не размалеван, как комикс для умственно неполноценных.

> Кроме того - интеграция (теминг вместе со всем остальным,

Таким способом ничего они не добьются. Надо делать server-side widgets.

> использование gconf

Кому-то не дают покоя лавры Windows registry...

> Это точно, хотя всякие чиста-крутые [censored], ненавидящее GNOME непонятно за что

Библиотеки и впрямь хорошие -- достаточно вспомнить хотя бы glib и gtk. Но это не оправдание тупому копированию несуразностей виндовой GUIни.

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

> Слышал про GNOME HIG? > If you can't make it good, make it look good. Вот к этому он и > сводится.

Ну ты и тупица. Даже говорить с тобой ломает. Где у гнома плохие программы?

> Так вот у firefox generic-интерфейс, не соотв. GNOME HIG (human interface guidelines). > Ага, не размалеван, как комикс для умственно неполноценных.

Не путай GNOME с KDE (сорри, кого обидел), это не одно и тоже.

> Кроме того - интеграция (теминг вместе со всем остальным, > Таким способом ничего они не добьются. Надо делать server-side > widgets.

Сам-то понял чего написал?

> использование gconf > Кому-то не дают покоя лавры Windows registry...

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

> Это точно, хотя всякие чиста-крутые [censored], ненавидящее GNOME > непонятно за что

Библиотеки и впрямь хорошие -- достаточно вспомнить хотя бы glib и gtk. Но это не оправдание тупому копированию несуразностей виндовой GUIни.

Что в GNOME было _скопировано_ с GUI виндоус. Конкретные примеры в студию.

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

>If you can't make it good, make it look good. Вот к этому он и сводится.

Насмешил. Гномовский HIG в большей своей части сводится именно к тому как следует ДЕЛАТЬ хороший GUI. Хотя, разумеется, по внешнему виду там также много сказано.

>Ага, не размалеван, как комикс для умственно неполноценных.

Ну ты даешь...

Чаще всего сейчас в гноме используются три темы: дефолтная, industrial, Blue Curve. Первые две - очень сдержанные, так что о "размалеванности" говорить не приходится. Blue Curve - более яркая, но при этом ее умудрились сделать не очень раздражающей (хотя многим не нравится).

>Таким способом ничего они не добьются. Надо делать server-side widgets.

А это не то что к Гному не относится, это по большому счету относится к линуху очень частично, client-side widgets - это особенность всех Unix-подобных систем. И ломать это - создавать массу проблем.

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

Windows registry vs gconf

> Скажи, а чем плох реестр в Windows, кроме реализации?

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

> Он не похож на ресстр винды. Он не в одном файле

А реестр что, в одном файле? RTFM, батенька, RTFM.

> И ключи не набор букв и цифр, а вполне английские слова.

Помедитируйте на досуге над /etc/gconf/gconf.xml.defaults/apps/metacity/general/%gconf.xml

> Что в GNOME было _скопировано_ с GUI виндоус. Конкретные примеры в студию.

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

> Сам-то понял чего написал?

Понял. Это по поводу теминга было. Если widget'-ами рулит X'-сервер, то такая проблема вообще не возникнет.

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

Понятие плохой программы - это вообще беспредметный разговор. Например, уважаемый DSelect объявит гнумерик плохим, потому что он не воспроизводит арифметические ошибки екселя. Может, именно это делает гнумерик плохим для г-на DSelect. Само слово "плохой" - это не качество программы, это оценка. И кто знает, на основании чего сделана такая оценка?

HIG, если и скопирован, то с маковских стандартов, а не с винюковых. Просто многие из тех, кто ругают гном, маков не видели. И маковских доков на интерфейсы.

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

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

> дефолтная, industrial, Blue Curve. Первые две - очень сдержанные,

Сдержанные?! Вы CDE когда-нибудь видели?

> А это не то что к Гному не относится

Отож. Каждая программа своим делом должна заниматься.

> client-side widgets - это особенность всех Unix-подобных систем.

У всех Unix-подобных систем есть стандартный GUI toolkit -- Motif. Хотя это тоже не решение проблемы, а уход от нее.

> И ломать это - создавать массу проблем.

Ну и что теперь, до скончания мира мучиться?

Dselect ★★★
()
Ответ на: Windows registry vs gconf от Dselect

А где приличному приложению сохранить последнее положение окошка? В $HOME/.applicationrc? Нефиг, в сад. Система конфигурирования должна быть единой, одной.

registry в винюках больше чем в одном файле. То ли в двух, то ли в трех. В любом случае - в гконф нынче таких файлов огромное кол-во. Впрочем, это детали реализации бекенда. Вы мне лучше скажите, можно ли винюковое регистри положить в ldap (не active directory)? А гконф, в принципе, можно - только один бекенд добавить.

Указанный файл прочитал - прекрасно он читается. Единственное, что не смог прочитать - перевести таймстампы в понятную форму гг-мм-дд чч:мм:сс. Но, надеюсь, это не дает основание считать формат нечитаемым.

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

svu ★★★★★
()
Ответ на: Windows registry vs gconf от Dselect

> А реестр что, в одном файле? RTFM, батенька, RTFM.

В очень малом количестве файлов. Так подойдет?

> Помедитируйте на досуге над /etc/gconf/gconf.xml.defaults/apps/metacity/general/%gconf.xml

apt-get install gconf-editor

> Да, я знаю, можно все настроить, а еще лучше -- снести нафиг убожество metacity и поставить что-то более дельное (sawfish, например).

И настраивать его. ;-)))

Чем вам всем метасити так не нравится. Хороший WM, все стандарты держит, работает без глюков и делает свое дело - менеджерит окна. И темится удобно.

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

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

Аналогично. Хотя в gconf я только положение кнопок поменял.

Вообще мне нравится ГНОМ, потому что у него немного самых настроек в окошках - это не раздражает, но при этом можно настроить более серьезно, через gconf. Кстати новый gconf-editor наконецто сохраняет описание, если ключ был изменен - это радует.

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

> > Да, я знаю, можно все настроить, а еще лучше -- снести нафиг убожество metacity и поставить что-то более дельное (sawfish, например).

> И настраивать его. ;-)))

Дык у него есть GUIевый настройщик, вполне удобный, IMHO.

> Чем вам всем метасити так не нравится.

Нету window groups, window matching...

> И темится удобно.

Точно так же, как и sawfish -- берет настройки из GTK темы.

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

> registry в винюках больше чем в одном файле. То ли в двух, то ли в трех.

RTFM (если только речь не о m$ Тамагочи 98).

> Только призываю еще раз вспомнить, на кого ориентируется гном.

Дык я _ИМЕННО_ за это не него и ругаюсь, если Вы еще не поняли.

> Кстати, нынешней метасити для моих скромных нужд вполне хватает

Я просто ленивый, поэтому поручаю раскидывать окошки по workspace'-ам, ставить нужные размеры и состояние window manager'-у :)

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

> Дык у него есть GUIевый настройщик, вполне удобный, IMHO.

У метасити нету??? ;-[ ] :)

> Нету window groups, window matching...

Есть.

> Точно так же, как и sawfish -- берет настройки из GTK темы.

Цвета что-ли? Я говорю про формы.

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

> Сам то понял что сказал? Каких ещё лагов?

BlackNight не стоит понтоваться своей ограниченностью.

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

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

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

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

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

> Готов спорить, что меньше, чем у gconf (хотя, повторюсь, в gconf это просто детали реализации).

Несколько сотен, AFAIK.

> Вопрос про альтернативные бекенды я уже задавал.

Для registry он есть, для gconf (пока?) нету.

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

Если я не знаю смысла ключей, то я не починю ни gconf, ни registry. А "текстовые" файлы, это хорошо, конечно, но на скорость работы они влияют не в лучшую сторону. > Еще гном хорош свое политикой интеграции десктопа

<IMHO>

Для того, чтоб приложения умели друг с другом работать, нужно пинать kernel hackers на предмет _нормального_ [IR]PC. Для того, чтобы GUI более-менее прилично выглядел (но при этом таки был настраиваемым), нужно пинать XFree86 hackers на предмет server-side widgets.

А всякие bonobo, gnome-vfs -- это грязные хаки (как и KPart/Kioslave). </IMHO>

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

1) UNIX'-ам там не место. Точка.

2) Если уж из NT получилась m$ Windoze, то что получится из Linux, и подумать страшно...

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

Re[5]: Windows registry vs gconf

Нормальная, универсальная система обмена сообщениями уже существует и активно развивается - это D-BUS. И поддерживать ее будут и KDE, и GNOME. И работать она будет в userspace - нечего все подряд в ядро пихать.

По поводу server-side widgets - тебе захотелось танцев с бубном как в винде всякий раз, когда надо чуть-чуть изменить дефолтный интерфейс? Жалко, что в Qt и GTK+ все рисуется самим тулкитом, все виджеты организованы в иерархию наследования и можно перекрыть пару методов, а не переписывать весь look&feel заново? А в винде все GUI'шные ОО-библиотеки висят на ее родной системе контролов, как на корове седло. Точно так же будет и с server-side widgets, разорви их шайтан.

balu
()
Ответ на: Re[5]: Windows registry vs gconf от balu

Да, d-bus это просто сказка. Это - надежда свободного десктопа. И рулез форево. Наконец-то будет нормально реализован клипборд между всеми с любыми данными, нотификация, и т.п. И все это унифицировано. Freedesktop.org - forver and the best!

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

Несколько сотен файлов в винюковом реестре??? Для меня это действительно новость. Вас не затруднит указать каталог, где лежит это все богатство?

Альтернативный бекенд реестра - это что? Да, для гконфа, кстати, есть альтернативный бекенд на Berkley DB (http://perkypants.org/projects/gnome-2.0-interviews/gconf/).

Если Вы не знаете смысла ключей - Вы не почините, это правда. Но ключи, как было уже указано, в большинстве случаев вполне читаемы и понятны. Разумеется, это зависит от авторов приложения. Но в реестре проблема двойная - сначала докопаться до ключей и значений (в двоичном формате), потом понять смысл ключей. Ладно, это все мелочи реализации одного из бекендов гконфа (в конце концов, двоичные файлы Berkley DB я тоже прочесть в редакторе не смогу).

При чем тут kernel hackers и нормальный rpc? Гном должен работать не только на линухе. И поэтому требовать от ядра чего-то особого не может - на других унихах этих супер-сервисов просто не окажется. Сервер-сайд виджетс - тоже утопия в современных иксах - потому как кроме xfree есть другие серверы (уже даже на писюках идет процесс размножения серверов - особенно в связи с новой лицензией). А еще есть удаленный режим работы - и там вообще ничего предсказать нельзя, там вообще какой-нибудь винюковый икс-сервер может быть.

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

Короче, гному приходится жить в реальном мире сегодняшнего униха - и, ей-богу, он вполне неплохо справляется.

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

svu ★★★★★
()
Ответ на: Re[5]: Windows registry vs gconf от balu

> Нормальная, универсальная система обмена сообщениями уже существует и активно развивается - это D-BUS. И поддерживать ее будут и KDE, и GNOME. И работать она будет в userspace - нечего все подряд в ядро пихать.

IPC и RPC при любом раскладе просто _обязано_ быть частью ядра. Собственно, это и есть то, чем ядро должно заниматься. А вот всякую фигню вроде FS, TCP/IP (и еще много чего) туда и впрямь незачем пихать (все, хватит разводить пропаганду микроядер:)).

> По поводу server-side widgets - тебе захотелось танцев с бубном как в винде всякий раз, когда надо чуть-чуть изменить дефолтный интерфейс?

А не надо его менять.

> Жалко, что в Qt и GTK+ все рисуется самим тулкитом

1) Это и есть основная причина пресловутой тормознутости X'-ов. И вроде как есть сетевая прозрачность, но без как минимум 10Mbit'-ной сети ее не видать, как своих ушей... 2) А что, кроме Qt и GTK больше никаких toolkit'-ов нет? И для каждого писать тысячу раз одно и то же?

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

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

>А вот всякую фигню вроде FS, TCP/IP (и еще много чего) туда и впрямь
>незачем пихать (все, хватит разводить пропаганду микроядер:)).

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

>Это и есть основная причина пресловутой тормознутости X'-ов. И вроде как
> есть сетевая прозрачность, но без как минимум 10Mbit'-ной сети ее не
>видать, как своих ушей...

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

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

> Несколько сотен файлов в винюковом реестре??? Для меня это действительно новость.

Поздравляю :) Новости о NT 3.5 достигли и Вас :) > Вас не затруднит указать каталог, где лежит это все богатство?

Разбросано по всей ФС.

HKEY_LOCAL_MACHINE\SYSTEM \Winnt\System32\Config\System

HKEY_LOCAL_MACHINE\SAM \Winnt\System32\Config\Sam

HKEY_LOCAL_MACHINE\SOFTWARE \Winnt\System32\Config\Software

HKEY_USERS\<SID or username> \Documents and Settings\<username>\Ntuser.dat

И еще дофигищи мест, где оно все валяется.

> Гном должен работать не только на линухе. И поэтому требовать от ядра чего-то особого не может - на других унихах этих супер-сервисов просто не окажется.

Более убогого RPC, чем у Linux, еще поискать надо... :(

> Сервер-сайд виджетс - тоже утопия в современных иксах

GTK есть и под DirectFB...

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

Не надо плодить сущности сверх меры.

> Гном-вфс - это действительно, в некотором смысле, хак.

Это в прямом смысле хак. Грязный хак.

> Вокруг тяжеловесной семантики униксовой файловой системы.

Вокруг убогой VFS монолитного ядра.

> Почему униксам не место на десктопе - мне совсем не понятно.

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

> Особенно, когда смотрю на маки.

Там от UNIX остались рожки да ножки. Так можно и NT с Interix'-ом UNIX'-ом обозвать...

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

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

Благородный дон когда нибудь видел QNX?

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

слизали всё с Mach/Hurd

имхо надо Hurd в массы помогать двигать

я позавчера пробовал ставил QNX - нахуй бы, у него лицензия коммерческая. обрезанный шелл, короче просто хз что

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

Да, linux -- монолитная система, и я согласен, что микроядро лучше.
Если бы у вашего сообщения не был такой спорный заголовок, я бы, вероятно,
согласился с большинством ваших высказываний. С теоретической (и
эстетической) точки зрения linux проигрывает. Если бы ядро GNU было готово
прошлой весной, я бы и не взялся за свою разработку: беда в том, что оно не
было готово тогда и не готово до сих пор. Linux выигрывает прежде всего
потому, что она уже готова. (Торавльдс в письме Таненбауму)

а GNU Hurd уже давным давно существует. и Darvin ещё есть и Mac OS X

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

А чего тебе в модулях не хватает? Разве что менять само ядро на лету. Дык думается, что скоро придумают как.

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


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

если у тебя сетка кампов то нагрузка может прозрачно балансироваться

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

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

> Да пусть пользуются, жалко что ли?

Dselect'у, по-видимому, не нравится, что куча народу пользуется Linux'ом на десктопе, решая свои задачи, и при этом зарабатывает сильно больше него.

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

чего не хватает

> А чего тебе в модулях не хватает?

http://www.debian.org/ports/hurd/hurd-doc-translator

Модули делают, что хотят. И частенько роняют ядро. :(

> Дык думается, что скоро придумают как.

То-то крякеры будут рады :(

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

не жалко, но...

уже появились патчи, уродующие ядро для "ускорения" X'-ов, KDE и прочей лабуды. Не приведи Великие Боги, чтобы эту муть включили в vanilla kernel...

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

> > Только призываю еще раз вспомнить, на кого ориентируется гном.

> Дык я _ИМЕННО_ за это не него и ругаюсь, если Вы еще не поняли.

Дык получается ты хернёй занимаешся :) Потому что тебе нечем занятся. Как говорят правильные хакеры "что-бы решить интересную проблему найди проблему которая тебя интересует"

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

Re[5]: Windows registry vs gconf

> А чего тебе в модулях не хватает? Разве что менять само ядро на лету.

где то было описание как это делать

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

> HIG, если и скопирован, то с маковских стандартов, а не с винюковых.

Из CDE, за основу был взят "Motif and CDE 2.1 Style Guide".

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

Ухх! Вы меня успокоили! Все-таки, не сотни - в пределах пары десятков. Да, про system32/config - это была новость, про ntuser.dat уже я знал. Только в system32/config файлов все-таки 20, при том, что там еще Event Log лежит. Так что вопрос о сотнях файлов остается открытым:) Прошу указать еще немного из той "дофигищи мест".

Про RPC - это интересно. Расскажите, чем доступные в линухе способы rpc хуже других. Вроде, все позиксовые стандартные методы работают. А чего Вам еще надо? Опять же, заточки "под конкретную систему" - это всегда плохо пахнет, код плодится, его как-то поддерживать нужно. А CORBA - это, все-таки, стандарт.

GTK есть под DirectFB. И даже под винюки. Но как основное направление развития эти среды никто не рассматривает - и это правильно. И GNOME (не GTK!) никто пока не собирался портировать с иксов на другие платформы.

Насчет расплодившихся иксов - согласен. Меня самого это очень раздражает (потому как каждая реализация добавляет свою кривизну в расширение XKB:). Но ведь это же неправильно - иметь единственную реализацию чего-нибудь. Linux is about choice:) Если серьезно - мы имеем то, что имеем. И единственный способ с этим сосуществовать - бороться за введение стандартов - а совсем не отстреливать тех, кто форкает xfree.

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

Unix изначально рассчитан на грамотоного пользователя, это правда. Но никому не запрещено выдать form-based интерфейс на каком-нибудь motif, в иксах, бухгалтеру - и он даже не будет догадываться, что где-то там есть сильно могутный шелл, какое-то там ядро и прочие мудрые вещи. Современный десктоп - тоже спокойно способен запрятать всю мошь униха под коврик (причем - не "с концами", а так, чтобы ее достать оттуда было можно, при желании - это важно, иначе я не согласен:).

Про то, что NT можно назвать униксом, Вы все-таки передергиваете. Все-таки макос - это микро-ядро с биэсдишной (униховой!) надстройкой, а дальше - "видимость" (собственная система конфигурации,аква и пр.). NT же, будучи изначально микроядром, так и не обзавелось приличной позиксовой системой. Зато подсистема win32 корни в ядро пустила.

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

:) Да, я про это читал. Буквы оттуда. Только посмотрев на то, какие люди там заправляют (например, на отцов почившего Eazel) - и куда идет процесс, я скорее ассоциирую эту культуру с маком.

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

Мне кажется, спор о gconf беспредметен. Это действительно нормальная система конфигурирования, по-крайней мере в интерфейсе, это признают все. Под интерфейсом может быть все, что угодно.

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

Но вот что хочется отметить, так это то, что unix/posix интерфейс стал действительно тяготить программирование на десктопе. Ну не нужны для приложения на десктопе posix threads и так далее. С этой точки зрения, объектно-ориентированные интерфейсы GNOME гораздо привлекательнее. А вот объекты, которые реализуют интерфейс Runnable довольно полезны. Поэтому когда речь заходит о поддержке всех остальных Unix, я не думаю, что это нужно. Тем более что и они уже ушли вперед своим путем, например сановская десятка.

Здесь можно отметить и проблему DBUS, дело в том, что это все-таки средство межпроцессного взаимодействия, а не межобъектного. То есть, в некотором смысле это шаг назад. Вызван он многими причинами. Многие программисты не принимают CORBA в GNOME только потому, что обслуживание такой инфраструктуры требует написания большого кода на C, во вторых, из-за неразвитости соответствующей инфраструктуры. Все-таки CORBA в GNOME один человек только занимается по-существу. в третих, тут есть и политические причины (RedHat vs Ximian). Все это очень грустно.

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

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

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

программистов спрос призывает и ясные цели. позиксовые функции ещё при компилировании можно автоматом заменить некоторые. кстати, NT полностью поддерживает позикс ?

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

> Мне кажется, спор о gconf беспредметен.

Согласен. Я просто хотел узнать побольше о реестре и его сотнях файлов:)

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

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

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

>программисты не принимают CORBA в GNOME ... потому, что ... требует написания большого кода на C

Извините, но мне сложно представить более-менее полную ОО модель взаимодействия, для которой код на С был бы коротким (любителям С++ просьба не беспокоиться). Но реально CORBA в GNOME мало кому нужна в чистом виде, для использования напрямую (хотя я одно время пользовал - вполне юзабельно!). Нужен бонобо (тоже подарочек - и вот тут-то действительно кода нужно понаписать немало:) А вот то, что всем этим занимается только Майкл Микс - возможно, проблема. У него головной боли и с ООо хватает.

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

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

> программистов спрос призывает и ясные цели. позиксовые функции ещё при компилировании можно автоматом заменить некоторые. кстати, NT полностью поддерживает позикс ?

при установленном SFU да. http://www.microsoft.com/windows/sfu/default.asp

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

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

>(только вот не появится ли линуксу более достойный конкурент то же

>из рядов GNU)

Уже появился - ФОСФОР называется -

http://beos.spb.ru/program/84/PhOSb5.iso.zip

------------- Не забудь cue-файл закачать для Nero.

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

Представим себе операционную систему без процессов - их заменяют объекты. Естественно, это не операционная система для серверов, и, тем более, не встраиваемая система. Преимущества такого подхода, кроме единой идеологии и сетевой распределенности, хотя бы в возможости той-же сериализации. Как раз проблемы возникают в Bonobo именно на почве процессов - трудно увязать объект, выполняющий методы, с процессом, в котором этот объект реализован. А что будет, когда в процессе реализовано несколько объектов? Возникают проблемы синхронизации, и почему-то в этом укоряют Bonobo, пытаясь заменить его на DBUS (он ведь ориентирован на процессы), но ведь это недостаток самой системы.

Если будет пример, SUN внесет необходимые изменения за год, и выпустит совместимую с такой операционную систему. А вот изменить что-то в Linux, так это, наверное, вообще невозможно. Наоборот, появятся куча противников, которые как раз будет протестовать против этих изменений, именно потому, что якобы нужно поддерживать POSIX, хотя сам по себе POSIX не нужен.

Более того, сановская десятка это прежде всего полноценная платформа для Javа приложений. Продукты Microsoft - полноценная платформа для .NET приложений. А Linux что поддерживает - POSIX и С?

Про то, что писать с ОО подходом и распределенно на С сложно, так кто же с этим спорит. Я не сторонник C++, я даже считаю, что в glib создана более удобная объектная система - например, есть сообщения и т.д. Но и она требует много кода. Я с завистью вспоминаю jav'у, когда мне приходится реализовывать очередной glib-овский класс. Но ведь не все сошлось на С.

Миша Микс действительно наш человек, но дел у него просто завались. Я не понимаю, неужели в ximian не нашлось другого человека для работы с OpenOffic'ом? Потому что работа над Bonobo и тем более над bonoboui встала совсем. Тут вообще интересный момент - с этим релизом многие проекты "встали". Почти нет изменений во всех библиотеках gnome (кроме gtk, gnome-vfs). Некоторые майнтейнеры вообще потерялись, как у libglade и vte. Все это заставляет задуматься.

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

У процесса - две точки соприкосновения с окружающим миром - ввод и вывод. Они присутствуют у всех процессов.

У "объектов" - месиво из методов, уникальных для каждого объекта.

Очевидно, что декомпозиция в множество процессов - более полное и красивое решение задачи, чем порождение кучи кривых объектов. Зачем тянуть ОС в темное прошлое?

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

> gentoo - кал

Нет, здесь кал - Gnome, Gentoo кал в соседнем треде

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

Почему ОО ОС не для серверов и не встраиваемая - мне, соббсно, не совсем понятно (ну, если не брать в расчет ресурсоемкость:). Уж для серверов-то сам Бог велел (точнее, Sun & J2EE:). В остальном, про процессы и объекты согласен. Но от процессов не убежать - это уних, джентльмены. Просто надо научить объекты мирно сосуществовать в рамках одного процесса:)

"якобы нужно поддерживать POSIX, хотя сам по себе POSIX не нужен". Не согласен. Позикс - необходим как минимальный набор сервисов и семантики. Или мы уже больше не играем в униховый десктоп и строим что-то другое (например, жабский десктоп:). Вопрос, насколько нужно надстраиваться над Позиксом... И вот тут очень нужна осторожность.

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

Миша Микс - ну, я бы не сказал, что именно "наш человек". Отпинываться от улучшений в бонобо он горазд. Хотя, возможно, именно в силу занятости. Но ведь "взялся за гуж..." Не говоря уж о том, что ему сам Бог велел свяать мост из UNO в бонобо - так ведь некогда ему... Короче, пора ему клонироваться...

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

Процессы дороги (хотя в унихе и дешевле, чем в NT). Нынче в гноме даже несколько экземпляров одного и того же апплета ЖИВУТ в ОДНОМ процессе!

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

> Процессы дороги

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

Процессы - _дёшевы_.

> Нынче в гноме даже несколько экземпляров одного и того же апплета

Внутри любой erlang-овской программы живут сотни и тысячи _дешёвейших_ процессов.

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

> Мы говорим про процессы, или нити?

Не хотелось бы упрекать вас в том, что вы пытаетесь меня поймать, но не могли бы вы уточнить вопрос?

1. Я говорил о том, что

a) В Solaris ядерные нити являются суровой необходимостью.

b) Они дороги и поэтому появляются многоуровневые M:N планировщики, сочетающие ядерные и пользовательские нити.

c) Это сочетание делает _процессы_ невыносимо дорогой вещью.

2. Процессы в erlang - несомненно пользовательские. Но это именно процессы, т.к. они используют только ввод (прием сообщения) и вывод (посылку сообщения).

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

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

Ядерные нити в Солярке действительно дороговаты. Поэтому M:N реализации пользовательских нитей необходимы. Кстати, с Линухом, насколько я знаю, тут забавнее. Была реализация M:N - но в последних ядрах (NPTL) снова стало 1:1 (т.е. каждый пользовательский тред имеет голову в ядре) - потому как ребята решили, что цена ядерного треда стала приемлемо дешевой.

_Процессы_ в Солярке дороги в связи с вышеуказанными причинами (и, подозреваю, есть еще другие причины, на связанные с нитями напрямую - например, отдельное адресное пространство кой-чего стОит).

Про ерланг я не понял, извините. Процессы в унихе - все-таки понятие ядерное (ну, я всегда так думал). Может, Вы имеете в виду, что там пользовательские нити?

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

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

> Про ерланг я не понял, извините. Процессы в унихе - все-таки понятие ядерное (ну, я всегда так думал). Может, Вы имеете в виду, что там пользовательские нити?

Я имел в виду пользовательский процесс :).

А нити (и пользовательские в том числе) имеют доступ к общему (адресному) пространству, процесс же такого доступа не имеет.

> Надо бы нам про терминологию договориться... Для меня процесс, в первую очередь, это отдельное адресное пространство (это не определение, упаси Боже, это одно из неотъемлемых свойств).

Именно. Но когда нет понятия `адреса' такое разделение сделать проще (и не обязательно на уровне ядра).

> И еще некоторое кол-во других ядерных объектов (всякой служебной информации, типа списков открытых файлы и пр.) А для вас?

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

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

монолитное ядро не подходит для desktop систем?

> Ухх! Вы меня успокоили! Все-таки, не сотни - в пределах пары десятков.

Гораздо больше. Особенно тех, где настройки COM+ лежат...

> gnome-vfs сделан так, чтобы работать на любом унихе,

Вашими устами да мед пить. Он и под Linux'-ом (не x86) м-м-м... не совсем хорошо работает...

> Я все-таки настаиваю на том, что gnome-vfs - хак (ну, грязный или нет - это вопрос личной оценки:) именно вокруг униксовой семантики файловой системы.

Hurd тоже придерживается POSIX семантики FS. И QNX. Так что это проблема именно "ядерной" VFS.

> Про RPC - это интересно. Расскажите, чем доступные в линухе способы rpc хуже других.

Нет LPC (a.k.a. Solaris doors), нет Secure RPC, нет распределенной памяти... Да и POSIX RPC тоже далек от совершенства, IMHO.

Мечта идиота состоит в том, ВСЕ должно выглядеть, как файл, а то, что это не файл, а какой-нибудь объект в памяти N-го количества хостов, должна знать только ОС.

> Все-таки макос - это микро-ядро

Нет, это не микроядро. Грубо говоря, такой же отхаканный Mach, как и NT.

> с биэсдишной (униховой!) надстройкой,

И еще с двумя, которые к UNIX никакого отношения не имеют.

> NT же, будучи изначально микроядром,

Никогда не была NT микроядром. Почитайте D.A. Solomon, M.E. Russinovich "Inside m$ Windows 2000".

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

Да, вынь32 подсистема -- одна из убийц NT.

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

Ну и нихрена себе ,воистину неисповедимы треды ЛОРовские. Начали с Gnome, через интеграцию-дезинтеграцию десктопа,закончили вообще архитектурными вопросами, скоро до железа дойдём ... ЗЫ: Там в топике про Gnome beta1 кто-то про интеграцию на низком уровне кричал ... ну, За что боролись ...

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

Не всосал ... ... ... Обтекаю ... :)

anonymous
()

> Гораздо больше. Особенно тех, где настройки COM+ лежат...

Где смотреть?

То, что где-то gnome-vfs работает хреново - это мы можем поскипать, мы же архитектуру базарим, правда? И как с этим связаны утверждения про Hurd/QNX - мне не очень понятно. Там легко-дешево примаунтить новую систему? И это может сделать каждый пользователь, не только рут? И геморроя с правами при таких маунтах нет? Я уже не спрашиваю про представление сетевых ресурсов (типа Network Neighborhood) в форме файловой системы - это, конечно, там все легко, прозрачно и доступно всем пользователям?

Про RPC увидел немного умных слов - а ЧЕМ именно эти RPC лучше того, что в линухе? Особенно если эти RPC все равно, по-хорошему, нужно потом оборачивать в ОО обертку (типа той же корбы или дибаса).

Про ядра микро-немикро-ядра макоса и НТ я почти поверил (хотя Вы сами себе противоречите: "такой же отхаканный Mach, как и NT" и "Никогда не была NT микроядром"). Я же говорю о том том, что НАД ядром - то, что могут и обычно используют прикладные программеры. Все-таки униховая подсистем в макосе дает возможность с минимальными усилиями собирать униховые проги. В НТ у Вас будут проблемы - без специальных усилий (и доп. средств) Вы униховые проги не соберете. Поэтому продолжаю считать Ваше утверждение, что макос - такой же уних, как и НТ - натяжкой.

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

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

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

>И как с этим связаны утверждения про Hurd/QNX - мне не очень понятно

И уж совсем непонятно ,как они связаны с Gnome 2.6 beta2 :)

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

И вот какая-то юзер-френдли поделка (Gnome) порождает споры системщиков по поводу внутренней архитектуры осей.

Линух бля ...

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

Ну не надо так болезненно реагировать. Но если желаете могу развернуть.

> Особенно с учетом того, что "процесс такого доступа не имеет"

Процесс имеет доступ к своему адресному пространству (набору биндингов). К адресному пространству (набору биндингов) другого процесса он доступа не имеет.

> И как из свойств процесса "выкинуть понятие 'адрес'" - тоже загадка.

См. выше.

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

Ну обсуждали же уже - ядерные нити дороги и они в ядре.

P.S. Еще раз прошу - не обижайтесь на тупые и неудачные шутки.

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

Судя по данному треду даже слишком взаимосвязано ,причём такими узлами что становится страшно ... :)

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

>P.S. Еще раз прошу - не обижайтесь на тупые и неудачные шутки.

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

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

threads & processes


в той же винде энти применяется объектно-ориентированный подход

например,
CreateXXX(...) где ХХХ название типа объекта системы, например сокет или файл или ещё что. при усложнении системы, АПИ очень удобный становится. а позикс в этом плане некрасивый, да и что зациклились все на нём ?


хороший микрокернел должен позволить не только процессам но и срэдам прозрачно распределяться в сети процессоров - то бишь я о кластерах

vm ★★
()
Ответ на: threads & processes от vm

> хороший микрокернел должен позволить не только процессам но и срэдам прозрачно распределяться в сети процессоров - то бишь я о кластерах

И в чем тут будет выигрыш для однопроцессорной системы, не подключенной к сети?

anonymous
()
Ответ на: threads & processes от vm

> в той же винде энти применяется объектно-ориентированный подход

Вот по этому винда рулит а лялих сосет

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

Так, про процессы и адреса стало понятно. Тогда скажите - те самые пресловутые эрланговские процессы живут в одном адресном пространстве (я не имею в виду их внутреннее представление о своей жизни, я про т.зр. ОС).

Похоже, все-таки Ваш пользовательский процесс - то же самое, что моя пользовательская нить.

А разве я обижаюсь? Я просто иногда удивляюсь:))

svu ★★★★★
()
Ответ на: threads & processes от vm

> хороший микрокернел должен позволить не только процессам но и срэдам прозрачно распределяться в сети процессоров - то бишь я о кластерах

А почему все в одну кучу (микроядерность и гибкая политика нитеделанья)? Что, "монолитный кернел" теперь стало ругательством на ЛОРе? Монолитный - так уж, значит, и нитки нормально распределить не могет?

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

> Тогда скажите - те самые пресловутые эрланговские процессы живут в одном адресном пространстве (я не имею в виду их внутреннее представление о своей жизни, я про т.зр. ОС).

С т.зр. ОС - естественно - естественно, они живут в одном адресном порстранстве. Но это не имеет _абсолютно_ никакого значения, так как для этих процессов нет понятия адреса.

Ведь, в конце концов, и "настоящие" процессы ОС живут в одном и том же _физическом_ адресном пространстве. Но это не имеет значения, т.к. они видят лишь линейные (виртуальные) адреса.

> Похоже, все-таки Ваш пользовательский процесс - то же самое, что моя пользовательская нить.

Ну пользовательские нити _разделяют_ общее адресное пространство (и прочие объекты ОС). Процессы же имеют собственный уникальный набор этих причиндалов.

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

> С т.зр. ОС - естественно - естественно, они живут в одном адресном порстранстве

> Ну пользовательские нити _разделяют_ общее адресное пространство

Во! Это разве не одно и то же (с т.зр. ОС)? Т.е. ОС создала адресное пространство (одно!) в рамках процесса (одного) - а уж живете вы там в нем или разделяете - это дело ваше. Получается (с т.зр. ОС), что все это богатство эрланга - один процесс, который (уже с т.зр. разработчика-пользователя-внутренней архитектуры) используется несколькими пользовательскими нитями. Вот и ура.

"Настоящие" процессы ОС живут в одном физическом пространстве, это да. Но мы же говорим про то, что ОС делает с этим физическим адресным пространством. И о том, что свое, независимое адресное пространство (в том смысле, в котором его понимает ОС, а не эрланг) отличает процесс от не-процесса.

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

> Где смотреть?

Это вопрос вида "Перечислить всех погибших на Великой Отечественной поименно". Ссылку на книжку я уже давал, а сам я не помню -- я эту муть лет 6 назад сдавал.

> То, что где-то gnome-vfs работает хреново - это мы можем поскипать, мы же архитектуру базарим, правда?

Дык работает она хреново в силу хреновой архитектуры.

> Там легко-дешево примаунтить новую систему?

RTFM: http://www.debian.org/ports/hurd/hurd-doc-translator

А вкратце:

Да (хотя там не монтирование, но фиг с ним). VFS там сидит в userspace. Поэтому ВСЕ приложения смогут использовать, скажем, ту же gnome vfs, если ее "уговорить" вести себя, как транслятор. И для этого их НЕ НУЖНО линковать с гномячими библиотеками.

> И это может сделать каждый пользователь, не только рут?

Да, если у него есть права на store и на транслируемый inode.

> И геморроя с правами при таких маунтах нет?

Грубо говоря, транслятор работает от имени пользователя, его запустившего.

> Я уже не спрашиваю про представление сетевых ресурсов (типа Network Neighborhood)

Ну, ftpfs есть :). Для того, чтоб ею пользоваться, никаких особых привилегий не надо.

> Про ядра микро-немикро-ядра макоса и НТ я почти поверил

Не надо никому верить, надо самому проверять.

http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/...

> Mach 3.0 was originally conceived as a simple, extensible, communications microkernel. It is capable of running as a stand&#8211;alone kernel, with other traditional operating-system services such as I/O, file systems, and networking stacks running as user-mode servers.

> However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks.

> Про RPC увидел немного умных слов - а ЧЕМ именно эти RPC лучше того, что в линухе?

Everything is file. В _буквальном_ смысле.

> Особенно если эти RPC все равно, по-хорошему, нужно потом оборачивать в ОО обертку (типа той же корбы или дибаса).

Нет, не надо! В ОО обертку надо будет завернуть POSIX read, open & friends. И все. > Все-таки униховая подсистем в макосе дает возможность с минимальными усилиями собирать униховые проги.

Почти с таким же сексом оно все собирается.

http://www.ginac.de/lists/ginac-list/msg01332.html

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

> Во! Это разве не одно и то же (с т.зр. ОС)?

Точка зрения ОС - это не та точка зрения, на которую нужно обращать внимание.

> Т.е. ОС создала адресное пространство (одно!) в рамках процесса (одного) - а уж живете вы там в нем или разделяете - это дело ваше.

Жить и разделять можно по разному.

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

А с точки зрения разработчика --- имеем кучу независимых и очень дешевых процессов. Ура.

> "Настоящие" процессы ОС живут в одном физическом пространстве, это да. Но мы же говорим про то, что ОС делает с этим физическим адресным пространством. И о том, что свое, независимое адресное пространство (в том смысле, в котором его понимает ОС, а не эрланг) отличает процесс от не-процесса.

Ну так у эрланговских процессов "адресное пространство" - свое, независимое, никак не пересекающееся с "адресным пространством" других эрланговских процессов.

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

Почитал доку о трансляторах. Ну да, hurd - типичный представитель микроядерных. Только мне кажется, это все-таки расширение традиционного униксового подхода к файловым системам (и не уверен, что это позикс-совместимо - надо посмотреть их стандарты, есть ли там что-нибудь на эту тему). Все-таки исходно уних не был рассчитыван на такие "вольности". Да, выглядит это прямее gnome-vfs, однозначно (можно даже повздыхать "почему в линухе не так?"). Но, повторяю, gnome-vfs было создано для "традиционной" модели, где просто так, с бухты-барахты, примаунтить кому попало, чего попало, куда попало не дают. В той же солярке (вторая по значимости платформа для линуха, как я понял) - насколько я помню, с подмаунчиваньем все достаточно строго. И раз так - приходится изобретать gnome-vfs (хотя было бы прикольно посмотреть на порт gnome-vfs для hurd, который был бы основан на трансляторах).

> Everything is file. В _буквальном_ смысле.

Это я понял. Я не понял, чем это облегчает rpc. Я, будучи программером, не считаю очень удобным rpc через файлы (хотя, конечно, сигналы еще хуже:). Лучше всего, конечно, что-нибудь типа corba - но рассчитывать на такой сервис со стороны ядра ОС не приходится - ему все-таки место на пользовательском уровне. А на нижнем уровне - любая сущность, которую можно читать-писать - сойдет. Те же старые добрые униховые fifo сойдут, по бедности. Или вам чего-то еще надо? Работало бы быстро и надежно...

> Нет, не надо! В ОО обертку надо будет завернуть POSIX read, open & friends. И все.

Хочу CORBA! Хочу какой-нибудь ОО RPC! Не хочу читать-писать! А-а! (плача и всхлипывая)

> Почти с таким же сексом оно все собирается.

Ну, не надо аргументировать отдельным примером такой глобальный тезис. Вон я на convex пытался собрать gcc и kaffe - такие грабли были, что мама - но это же не делает convex не-унихом. Вообще, недаром нет четкого единого определения униха (буквоедам просьба не беспокоиться) - есть некое "общее представление" (у каждого, кто достаточно долгое время общался с унихом) - и, мне кажется, макос укладывается в него значительно лучше (хотя очень многие части и выпирают), чем NT.

Кстати, если смотреть формально - разница между тем, что какой-то хидер не компилируется и тем, что такого хидера НЕТ ВООБЩЕ - очень большая:) Надеюсь, Вы понимаете, о чем я.

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

> Точка зрения ОС - это не та точка зрения, на которую нужно обращать внимание.

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

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

> Я-то как раз с т.зр. ОС и определял понятие процесса.

Я не виноват:

a) Сам спор завязался с "процессы vs объекты". Где вы видели объекты с точки зрения ОС?

b) Я несколько раз приводи свое определение процесса.

с) Само определение процесса "с точки зрения ОС" достаточно искусственно.

> А Вы, оказывается, с т.зр. виртуальной машины эрланга.

Ну что в этом плохого? Эти процессы не менее реальны, чем "настоящие". Даже более - их "адресные пространства" разграничиваются во время компиляции, а не в обработчике page fault.

> А ну как придется еще кто-нибудь и начнет говорить о физических процессах в процессоре...

Именно вы и говорили о каких-то "особенно настоящих" процессах.

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

А я говорил, что Вы виноваты?:)

Соббсно, я видел тему спора "процессы ОС - объекты сами по себе - или контейнеры объектов". Кстати, на уровне ОС есть объекты - все зависит от того, что мы вкладываем в это слово.

Ваше определения я видели (и, как Вы помните, запаниковал на этом месте:). Просто оно настолько не ложилось в те рамки, к которым я привык...

А чем "искусственно" определение объекта с т.зр. ОС? (кстати, снимаю шляпу - мне иногда кажется, что большинство ЛОРовцев испытвают проблемы со словом "искусственный" - как и вообще с русской речью:)

>> А Вы, оказывается, с т.зр. виртуальной машины эрланга.

>Ну что в этом плохого?

Ничего! Просто мы говорили о разных вещах!

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

Я, повторяю, говорил о процессах с т.зр. ОС. Ибо только в этом контексте можно разделять ядерные и пользовательские нити. Для виртуальной машины эрланга ядра не существует. И для жабской. И, вроде, для паскалевской тоже.

ЗЫ А вообще, очень было бы узнать, с кем имею честь. Зарегистрировались бы...

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

немного не в тему, учитывая что вы больше о высоких материях... :))
наверное если я зароюсь в манах, то найду ответ на свой вопрос (или не найду, что тожу будет своего рода ответом), но думаю тебе не составит труда ответить. а теперь вопрос:
WM предоставляет программе некоторые ресурсы (окно, полосу прокрутки, курсоры (м.б.) например), входит ли в число таких стандартных Х-ресурсов главное меню программы? формулируя по другому - есть ли такие WM, которые показывают меню подобно mac os, одна область, которую разделяют все программы и к которой получает доступ только активная?

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

и даже совсем по другому - есть ли возможность написания подобного WM при отсутствии такового? это я спрашиваю только потому что никогда не писал ничего под Х, да и вообще для GUI писал что-то всего два раза за десяток лет, а не потому что мне лениво разбираться самому (скорее потому что для разбора получится очень большой кусок)

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

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

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

Offtopic:
Уважаемый svu, к сожелению тред про ядро 2.6.4 кажется закончился и
Вы в нем говорили, что смогли запустить винмодем, не могли бы Вы
рассказать как? можно по мылу gelios at rbcmail dot ru. Заранее спасибо

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

Сначала думал ответить приватом - но потом решил - может, еще кому понадобится. Итак,

<offtopic>

<title>Установка интеловского модема в ядре 2.6.3</title>

<body> Речь идет о модеме smartlink. Чип выглядит так:

00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 03)

Насколько я понимаю, СУЩЕСТВЕННЫМ является именно то, что он из состава ICH4.

В последних версиях драйверов alsa есть драйвер snd-intel8x0m (буква m принципиальна), который и работает с dsp этого модема (насколько я понимаю). В ядрах 2.6.х этого модуля пока нет (в той версии alsa, которая включена в ядро), нужно добавлять его туда ручками. Он там скоро будет - но пока нет. Надеюсь, в следующем релизе. Итак, я взял alsa-drivers, взял slmodem-2.9.6.tar.gz. В самом slmodem есть патч для 2.6.х - его мне пришлось руками подриховать, чтобы он накладывался на редхатовское ядро - и заменил файл intel8x0m.c на более свежий (из alsa) - иначе просто не компилилось. Построил ядро (разумеется, включив CONFIG_SND_INTEL8X0M=m). После чего заменил в modprobe.conf "alias sound-slot-0 snd-intel8x0" на "alias sound-slot-0 snd-intel8x0m". Переставил ядро, перезагрузился.

Оно поднялось, загрузилось и пошло работать. Далее, я снова пошел в slmodem и сделал "make SUPPORT_ALSA=1". Получил приложение slmodemd. Запустил его. Автоматически появилось устройство /dev/ttySL0 (точнее, /dev/pts/1) :maj 136, min 1. Это и был винмодем:)

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

</body>

</offtopic>

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

Только что узнал - этот модуль уже в ядре. В БитКипере, во всяком случае. Таким образом, скоро народу останется только вторая часть балета.

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

to svu:

Еще раз соорри за оффтопик

><title>Установка интеловского модема в ядре 2.6.3</title>

Мммддаа, к сожелению это мне не поможет. У меня модем Supra 56i CW
с чиопм HCF от Conexanta. Производитель Diamond Multimedia.
Я конечно понимаю, что можно поставить дрова от linuxanta, но хотелось
бы решить не платя доп. 20 баков.
Нашел вот ссылку http://ndiswrapper.sourceforge.net/. Говорят, что
загрузчик драйверов у них такой же как и у линуксанта и способен
загрузить бинарные дрова от винды. Пока не пробовал, сегодня вечером
попробую.

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

А чего про него рассказывать? Я же рассказал основные куски. Во-первых, "основа" патча лежит внутри slmodem-2.9.6.tar.gz. Далее, выясняется, что бОльшая часть патча уже лежит в редхатовских ядрах - реально нужно только то, что запихивает intel-8x0m в конфигурацию ядра - и сам новый файл intel-8x0m.с Но при этом та версия файла, которая в патче - старая. Нужно взять новую из последней алсы.

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

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

Про ndiswrapper - да, смешная штука. И работает. Но у меня работало только на 2.4. Дело в том, что 2.6 злобно поломана сборка внешних модулей (и как результат, у меня внешние модули просто загрязняют ядро - и иногда просто рушат его). Это известная проблема и они ее пытаются решать. Надеюсь, решат скоро.

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

что стыдно перед окружающими у били отсасывать? :)

anonymous
()
Ответ на: threads & processes от vm

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

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

CORBA vs write()

> Хочу CORBA! Хочу какой-нибудь ОО RPC! Не хочу читать-писать! А-а! (плача и всхлипывая)

Дык это ж и есть [почти] OO RPC. Идея трансляторов как раз в том и состоит, чтоб предоставить интерфейс к _любому_ сколь угодно сложному IO|IPC|RPC в виде POSIX-подобных опреций с файлами.

Напр., можно gconf представить в виде ФС ( имя файла -- имя ключа, значение ключа -- содержимое файла). Тогда ключ менять можно просто: cat > /servers/gconf/applications/blah/blah

Dselect ★★★
()
Ответ на: CORBA vs write() от Dselect

CORBA vs write(), очепятки

%s/опреций/операций/g

Dselect ★★★
()
Ответ на: CORBA vs write() от Dselect

> к _любому_ сколь угодно сложному IO|IPC|RPC в виде POSIX-подобных опреций с файлами

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

Да, а еще Вы рискуете дойти до того, что Ваша файловая система просто ляжет под непосильным грузом псевдо-файлов (понятно, я не про диск - я про структуры ядра на уровне vnode). Т.е. требуется нехилое перетряхивание основ ФС ОС, чтобы это все работало эффективно. Возможно, переписывание ОС с нуля (и превращение ее в тот же plan9, в котором действительно "все есть файл").

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

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

Запости мне на мыло - я хочу этот вопрос включить в faq. Сам понимаешь - там надо все разжеванно и подробно.

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

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

Да.

> ОО интерфейсы слишком разнообразны, чтобы так просто их можно было "сплющить"

Не надо ничего сплющивать. Объект -- директория, свойство -- файл в этой директории, etc.

> Да традиционная файловая система и сама не справляется обходиться без ioctl (а дальше уж кто во что горазд), если уж на то пошло - что, опять же, демонстрирует неполноту идеи read/write.

Нет, это как раз демонстрирует неполноту ее реализации (раз есть вещи, недоступные через read/write)

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

VFS работает в userspace. И псевдо-файлов никаких нет.

> и превращение ее в тот же plan9, в котором действительно "все есть файл"

А чем это плохо?

> Напоследок, такая модель организации ОС уже точно за границей того, что называется "просто уних".

1) Понятие "просто UNIX" меняется со временем.

2) А какая разница? Наружу все равно торчит POSIX-образное API.

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

Ок. Вообще оно тут периодически везде всплывает.

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

> Объект -- директория, свойство -- файл в этой директории

А с методами-то что делать будем? Особенно с теми, которые и принимают, и возвращают значения? write_read атомарный? Мы же договорились реализовать полноценный ОО подход. Например, как в Вашем случае будет выглядить, скажем, метод панели, возвращающий список всех апплетов - и метод, возвращающий апплет на позиции idx?

> Нет, это как раз демонстрирует неполноту ее реализации (раз есть вещи, недоступные через read/write)

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

Да, если VFS в user space, конечно, ядру наплевать. Хотя даже на пользовательскую VFS нагрузочка может получиться немаленькая. Проц-то у нас один (или будем добавлять спец проц - как у next, только для файловых операций, а не dps?:) Соббсно, мысль моя в том, что программеру придется мучится сначала "укладывая" выпуклый ОО интерфейс в последовательность чтений-записей, а потом выполнять обратную работу (на стороне сервера-транслятора) - переводить потоки данных в вызовы к внутреннему объекту.

> > и превращение ее в тот же plan9, в котором действительно "все есть файл"

> А чем это плохо?

Ничем. Только plan9 - это не уних. Гном - униховый десктоп. Только и всего. Неувязочка.

> 1) Понятие "просто UNIX" меняется со временем.

Не согласен. Еще можно подумать, что меняется понятие "современный уних". Но понятие "просто уних" (в смысле "классический уних") - стабильно. И было сформировано в первые 5-10(-15?) лет существования.

> Наружу все равно торчит POSIX-образное API.

Ну, такое API и в винюках есть. Только это не делает их унихом. Дело не в этом. А в том, что гном не имеет права рассчитывать на существование такого API (не в смысле наличия функций, а в смысле семантики, которая за ними). Он может рассчитывать только на обычные файлы и каталоги, симлинки, файлы устройств. Даже на /proc он рассчитывать не имеет права, в общем случае.

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

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

> А с методами-то что делать будем?

Тоже самое -- все есть файл.

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

cat /servers/gnome-vfs/panel/applets/all

:)

> метод, возвращающий апплет на позиции idx?

stat называется. Файл и директория -- это одно и то же :))

> Особенно с теми, которые и принимают, и возвращают значения?

А в чем проблема-то?

write -- принимаем значение, read -- отдаем результат. Где проблема-то?

> Ничем. Только plan9 - это не уних. Гном - униховый десктоп. Только и всего. Неувязочка.

Т.е., портировать GNOME например, на Hurd никто не собирается?

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

Как раз именно для этого VFS и создавалась. Только тот факт, что она рвботала внутри ядра, практически сводит на нет ее преимущества.

> Соббсно, мысль моя в том, что программеру придется мучится сначала "укладывая" выпуклый ОО интерфейс в последовательность чтений-записей, а потом выполнять обратную работу (на стороне сервера-транслятора) - переводить потоки данных в вызовы к внутреннему объекту.

1) А IDL уже отменили?

2) А CORBA|DCOM чем лучше?

> Ну, такое API и в винюках есть.

> Ну, такое API и в винюках есть. Только это не делает их унихом.

Да, потому что есть "более равная" win32 подсистема.

> А в том, что гном не имеет права рассчитывать на существование такого API (не в смысле наличия функций, а в смысле семантики, которая за ними).

... и поэтому сам занимается реализацией такой семантики. И KDE делает то же самое. И (казалось бы, что общего у desktop environment и системы обработки данных) ROOT ( См. http://root.cern.ch). И даже у убогого mc есть своя VFS. Вам не кажется, что неправильно?

Ежики кололись, плакали, но продолжали жрать кактус. :(

> Даже на /proc он рассчитывать не имеет права, в общем случае.

И на X window system, потому как она не POSIX :)

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

Про апплеты понял. Да, неудачный пример:)

> А в чем проблема-то? write -- принимаем значение, read -- отдаем результат. Где проблема-то?

А если два процесса одновременно будут читать из одного файла, после записи в него же? race conditions не боимся?

> Т.е., портировать GNOME например, на Hurd никто не собирается?

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

> 1) А IDL уже отменили?

> 2) А CORBA|DCOM чем лучше?

Ура. Если IDL спрячет от меня все эти богатства OO FS-RPC и оставит мне корбу или любой другой нормальный call-based OO API - я согласен на все:)

> И даже у убогого mc есть своя VFS. Вам не кажется, что неправильно?

Да, это перебор. Поэтому я смотрю на freedesktop.org - единственное место, где смогут договориться о чем-то подобном и реализовать. Если смогут, конечно.

> И на X window system, потому как она не POSIX :)

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

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

Точно не помню. Может быть, Кристиан. А может, просто accounts at gnome dot org

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

> и оставит мне корбу или любой другой нормальный call-based OO API

Call-based API -- нормальный? Мсье знает толк в извращениях...

> Поэтому я смотрю на freedesktop.org - единственное место, где смогут договориться о чем-то подобном и реализовать.

Такая функциональность нужна не только -- и не столько -- разного рода desktop environment'-ам.

> Она, кстати, вроде, IEEE - или я чего-то путаю?

Вы чего-то путаете.

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

А почему call-based API - извращение? И давно это стало извращением? Как-то я отстал от жизни...

Ну, под десктопом лежит много чего. Например, libxml, pkgconfig - они, хоть и на freedesktop.org, полезны не только на десктопе.

Да, про IEEE это я погорячился. Дело ограничивается X Consortium (известным нынче как x.org)

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

Да, про атомарный read_write есть решение в рамках классической семантики, но с временными файлами. Но Боже, какой же это изврат!!!

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

Посмотрел быстро. Ну, местами интересно. Как решается проблема атомарного read/write на файловой системе, не понял. Буду смотреть еще раз, медленно:).

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

2BaT:
> О, svu, я тоже хочу мыло на gnome.org :) Расскажи, как получить :)
У тебя ж есть право на запись в репозиторий, значит, есть и алиас на gnome.org ровно с твоим логином.

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

В общем случае, это несвязанные вещи. Во всякому случае, мыло я получил сильно позже, чем доступ к cvs

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