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

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

btw: у меня такое впечатление, что переезд лора на fc4 - плохая идея.

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

>Что сломали?

c++ abi. по крайней мере на эту тему в листе дебьяна был немаленький такой опус.

>человек нарывается на то что уже обсуждали на проблему различия объектных моделей и тп

да нет. это ты нарываешься.

я всего лишь указал на то, что C куда ближе к архитектуре существующих компьютеров, чем C++. Любой вызов виртуального метода - это извлечение адреса _функции_(!) из vTable и вызов этой _функции_(!), которая первым параметром принимает указатель на экземпляр класса.

если ты не понял: C++ вынужден опускаться на процедурный уровень для вызова метода

если опять не понял: тот же call (про фреймы и обработку исключений пропустим, ок?) только более сложный чем в C

>если такое различие очень сильное то тут что С что С++ одна херовина

С всё-таки более низкоуровневый язык, чем C++. Так что может и херовина, но не одна.

>Кстати, когда гном перешел на 2.0 и началась ломка стереотипов - меня тоже немало колбасило. И я иногда думал: "Плюну на все и уйду помогать кдешникам". Но следующая же мысль "у них там плюсы" вызывала рвотный рефлекс такой силы, что...

У них там в kdebingings для прикручивания разных языков есть биндинг Qt на C. По использованию, вроде, на glib похож :)

>Куда у тебя Gnome валится? Понавылезали....

Понавылезало у тебя кое что из штанов. А я культурно пишу в форуме.

Не "куда валится", а валится, падает, crash. Доступно объясняю? Гном у меня запускается. Но он же у меня глючит. Что касается заявлений geek'а про то, что дистрибутив у меня экспериментальный, могу заметить, что с KDE при всей экспериментальности дистрибутива, ничего не происходит - rock stable.

>> Что касается внешнего вида - с версии 2.4 не вижу изменений. >А тебе какие нужны? Что бы как у M$, на каждую версию устраивать новый взрыв на складе лакокрасочных изделий?

Охлади свой пыл. И читай вместе с моими ответами вопросы, невнимательный ты наш.

Мне тут geek заявил, что в gnome вылизывают не только внутреннюю структуру, но и внешний вид. В связи с чем возник вопрос - где изменения. И не надо мне тут в морду MS тыкать, коли читать не умеешь.

>Интересно, почему-то те, кто не любят гном также не любят и XML. Влияет уровень инноваций? И неприспособленность к ним мозга?

Нет. Просто мы считаем, что не нужно пихать xml во все дыры. XML - не панацея. И если можно сделать читабельный конфиги как в KDE или любом WM, зачем их делать в xml?

>Мне тут geek заявил, что в gnome вылизывают не только внутреннюю структуру, но и внешний вид. В связи с чем возник вопрос - где изменения.

изменения? в гноме все выглядит одинаково и без отклонений от стандарта. вылизывание заключается в приведении аппликухи к соответствию с HIG прежде чем включить её в состав гнома.

Ну сколько раз твердили миру... XML - деталь реализации простейшего бекенда к gconf. Хотите - за деньги бекенд в лисповой форме напишу?:) Годится любое хранилище, способное держать дерево.

Угу. Лошадь С позади телеги С++. А за ними будет, матерясь, бежать всадник svu...

>Про позикс - это я к тому, что даже если микроядро и-или отдельные модули будут на плюсах, libc в любом случае делать придется. На С.

Я может что-то путаю, но вроде есть реализация libc на c++.

P.S. А не пофигу ли на чем писать, если люди это умеют?

Да, плохо выразился. Даже libc на с++ (а что, есть такие?) не отменят необходимости использовать extern C. Если люди умеют - пофиг на чем писать. Вопрос в иллюзиях об умении, которые так мастерски создает С++. И о том, стОит разгрести завалы после "умельцев".

>P.S. А не пофигу ли на чем писать, если люди это умеют?

Про тяжесть использования c++ библиотек из других (даже ООП) языков уже разжовано до кварков. Так что не пофигу.

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

Это известная сложность - переучить сишника на c++.

Пофиг - на чем аппликухи. Не пофиг - на чем фреймворки. Платформообразующие либы.

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

>Потому и вижу xxkb на каждом втором кдешном скриншоте - местная-то переключалка кривовата чуток

Говорят, что уже нормальная, но сила привычки. К тому же xxkb использовать с kde не очень кошерно - лучше kkbswitch.

>Не пофиг - на чем фреймворки. Платформообразующие либы.

гм. я именно это и говорю

Вот kkbswitch - да, более прямая штука. Но, вроде, она только индицировать может, не отображать. Я ошибаюсь?

>> Вопрос в иллюзиях об умении, которые так мастерски создает С++

даже сейчас я не считаю что у меню на нем писать :)))
- это не есть хорошее чувство - самодовольство :)

и учится всегда нужно :)

Увы, слишком много я встречал плюсистов с таким вот нехорошим чувством:) Кстати, я немного умел (ну, на С++ тех лет) - но за 10 лет наверняка разучился:)

>пожалуйста, скажите что я не прав и постоянные падения сервера - это железо

К сожалению я не обладаю информацией о том, почему лор падает и падает ли он, или это падает соединение у провайдера.

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

Возможно, что она падает из-за проблем с ядром, которое в fc собрали через одно место. Помогает пересборка.

>С всё-таки более низкоуровневый язык, чем C++. Так что может и херовина, но не одна.

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

>>человек нарывается на то что уже обсуждали на проблему различия объектных моделей и тп

>да нет. это ты нарываешься.

>я всего лишь указал на то, что C куда ближе к архитектуре существующих компьютеров, чем C++. Любой вызов виртуального метода - это извлечение адреса _функции_(!) из vTable и вызов этой _функции_(!), которая первым параметром принимает указатель на экземпляр класса.

>если ты не понял: C++ вынужден опускаться на процедурный уровень для вызова метода

>если опять не понял: тот же call (про фреймы и обработку исключений пропустим, ок?) только более сложный чем в C

>>если такое различие очень сильное то тут что С что С++ одна херовина

>С всё-таки более низкоуровневый язык, чем C++. Так что может и херовина, но не одна.


c++ по нижней точке не отличается от С
...... АБСОЛЮТНО !
он специально был таким задуман
с++ никуда не опускается - он делает только то что нужно
он так же близок к архитектуре существующих компьютеров как и С
..... мать мать мать --- привычно отозвалось эхо ...
и если существует объектная модель реализованая на С и предметная модель реализованая внутри этой объектной модели на то м же С
то в С++ исчезает лишняя деталь- самопальная объектная модель
НО ПРОБЛЕМА согласования объектных моделей будет всегда
...... не звени на язык который ты совершенно не знаешь
... матом бы ... да в приличном обществе ....

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

Я по диагонали посмотрел hig и кое-какие интересующие меня пункты прочитал. Хочу заметить, что hig в общем-то не отличается от рекомендаций дизайнеров. И ничего нового, никаких открытий не видно.

>Годится любое хранилище, способное держать дерево

Хочу поинтересоваться, как без этого обходится kde?

>Про тяжесть использования c++ библиотек из других (даже ООП) языков уже разжовано до кварков. Так что не пофигу.

Но проблема решаемая же?

>Но, вроде, она только индицировать может, не отображать.

Не понял предложения.

>c++ по нижней точке не отличается от С ...... АБСОЛЮТНО !

ключевые слова - "в нижней точке". Ты упорно игнорируешь тот факт, что на этот уровень вызов надо ещё опустить.

>он так же близок к архитектуре существующих компьютеров как и С

опять же - "в нижней точке". Объекты лежат чуть повыше этого минимума =)

>НО ПРОБЛЕМА согласования объектных моделей будет всегда

а я что сказал? =)

ты же хочешь ПРОБЛЕНЫЙ ООП запихать на нижний уровень системы.

>Но проблема решаемая же?

решаемая. но оверхед присутствует

> обходится kde?

Не обходится. Где в кде нормальное централизованное администрирование (киоск-моду не предлагать).

>Аргументов о преимуществах sim жду уже несколько месяцев. У вас есть аргументы? :)

Вагон.

1. Не вижу плавающих окон на пользователя. Давно есть в icq, есть в sim.

2. Не вижу режима invisible и списков видимость/невидимость (по крайней мере смотрел только что - возможно, есть где-то в нелегко доступном месте?).

3. Хотел бы плагин для погоды.

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

5. Не вижу кнопки "не выводить по группам".

6. Он работает через https?

Виноват, думал о постороннем:) Индицировать, не КОНФИГУРИРОВАТЬ.

>решаемая. но оверхед присутствует

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

>Не обходится. Где в кде нормальное централизованное администрирование (киоск-моду не предлагать).

Что ты понимаешь под нормальным централизованным администрированием?

>>Но проблема решаемая же?
>решаемая. но оверхед присутствует

ну и приведи мне пример
отсутствия оверхеда при согласовании объектной модели гнома и смолтолка например

и покажи что он будет меньше чем для qt - smalltalk

что нить простенькое - выжимку

>>c++ по нижней точке не отличается от С ...... АБСОЛЮТНО !
>ключевые слова - "в нижней точке". Ты упорно игнорируешь тот факт, что на этот уровень вызов надо ещё опустить.

чаво ??!!!
ты хочешь сказать что void call_me_please ();
надо куда то опускать ?

>он так же близок к архитектуре существующих компьютеров как и С
опять же - "в нижней точке". Объекты лежат чуть повыше этого минимума =)

и ты хочешь сказать что гномовская модель лежит ниже этого минимума ?

>>> ты же хочешь ПРОБЛЕНЫЙ ООП запихать на нижний уровень системы.

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

>С всё-таки более низкоуровневый язык, чем C++. Так что может и херовина, но не одна.

Это один и тот же язык. если - нет, то гтк-шный "си" никакой не си.

Указание умолчательных значений для разных групп конфигурационных переменных (вплоть до отдельных переменных). Указание прав доступа для разных групп конфигурационных переменных (вплоть до отдельных переменных). Все это на per user, per group основе. gconf все это позволяет, при наличии соотв. бекенда (типа ldap). Как это сделать в kde?

>Угу. Лошадь С позади телеги С++. А за ними будет, матерясь, бежать всадник svu...

Лошадь прибита к телеге, потому как её часть :)

Например, http://www.gnome.org/~seth/blog/sabayon - как сделать это в kde?

> >знаешь, сколько на буке с 128 метрами будут собираться kdelibs? да если ещё и найсом затормозить?

> Столько же, как если бы это была бука с 1024 метрами памяти. Посмотри ради интереса top во время сборки. Тебя удивит.

IMHO, если при сборке используется ключ -pipe (а он почти везде by default), то разница будет заметная.

К примеру, на 128 MB у меня в свое время Firefox собирался раза в 2 дольше чем сейчас на 640.

Мы ж не про языки, мы ж про kdeшные apis. Да и поток матюгов от всадника этим не уменьшишь:)

> Не обходится. Где в кде нормальное централизованное > администрирование (киоск-моду не предлагать).

Где в Gnome нормальное централизованное администрирование? GConf- не предлагать.

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

> Просто мы считаем, что не нужно пихать xml во все дыры. XML - не панацея. И если можно сделать читабельный конфиги как в KDE или любом WM, зачем их делать в xml?

Я тут недавно запустил 'make update-po' в каталоге 'po' свежего среза GIMP. Пока скрипт отрабатывался, я успел переодеться, сходить в патерсон за ужином и вернуться (минут 8-10).

Сразу после этого запустил 'lupdate -verbose -noobselete Scribus.pro', чтобы обновить XML-ные переводные файлы TS. Только зевнул три секунды, как всё уже готово.

Это к вопросу XML vs plain text

> Я по диагонали посмотрел hig и кое-какие интересующие меня пункты прочитал. Хочу заметить, что hig в общем-то не отличается от рекомендаций дизайнеров. И ничего нового, никаких открытий не видно.

HIG - это не маркетоидный бренд, это комплекс рекомендаций. Он не обязан быть суперинновационным.

скажем дружно - нафиг нужно. кде не для секретарш типа геека или тебя. он для фо фан.

Платформо-образующий C и безопасность

Если в GTK в качестве платформо-образующего языка взят C, то как там обстоят дела с безопасностью?

Одним из главных бичей Win32 и COM является таки как раз проблема с безопасностью. Точнее на нее в своя время обращали слишком мало внимания, если, вообще, обращали :) Под безопасностью я понимаю примерно то, что существует сейчас в Corba, Java2 и .NET как одно из важных составляющих каждой из перечисленных выше платформ. Тогда интересно, а что мы получим, если начнем строить платформу на основе простого C?

Это больше вопрос не относительно GTK, а относительно того, насколько возможно и целесообразно в принципе строить платформу на основе языка программирования C. Потом мне кажется, что Qt - это прежде всего отличный тулкит для C++, но никак не платформа.

P.S. Надеюсь, мы одинаково используем слово "платформа"? :)