[devel] Torque Installer

[devel] Torque Installer

[Yury Umanets]

Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. Может 
кто чего скажет об потрохах? Кто смотрел?
Мне там конечно не все нравится, в последнее время был сильно занят. Так 
что ...

-- 
Yury Umanets,
ALT Linux Team

Re: [devel] Torque Installer

[Alexander Bokovoy]

On Tue, Jan 15, 2002 at 11:45:29AM +0200, Yury Umanets wrote:
> Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. Может 
> кто чего скажет об потрохах? Кто смотрел?
> Мне там конечно не все нравится, в последнее время был сильно занят. Так 
> что ...
Собрать -- собрал, но запустить так и не смог. Как в mono, так и в
нормальном режиме говорит, что не может проинициализировать модули.
-- 
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
  `Senior software developer and analyst for SaM-Solutions Ltd.`
---
Nov 21 20:58:58 alconost kernel: VFS: Busy inodes after unmount. 
		    Self-destruct in 5 seconds.  Have a nice day...

Re: [devel] Torque Installer

[Stanislav Ievlev]

Yury Umanets wrote:

> Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. 
> Может кто чего скажет об потрохах? Кто смотрел?
> Мне там конечно не все нравится, в последнее время был сильно занят. 
> Так что ...

Не посмотрел, но собрал и даже запустил.

У нас тут проблемы с дозвоном до linux.kiev.ua - поэтому еще не все 
посмотрели

Сегодня планирую посмотреть код подробнее.

Как делается консольный инсталлятор?

>

Re: [devel] Torque Installer

[Aleksey Novodvorsky]

Yury Umanets wrote:

> Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. Может
> кто чего скажет об потрохах? Кто смотрел?
> Мне там конечно не все нравится, в последнее время был сильно занят. Так
> что ...

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

Rgrds, AEN

Re: [devel] Torque Installer

[Yury Umanets]

Alexander Bokovoy wrote:

>On Tue, Jan 15, 2002 at 11:45:29AM +0200, Yury Umanets wrote:
>
>>Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. Может 
>>кто чего скажет об потрохах? Кто смотрел?
>>Мне там конечно не все нравится, в последнее время был сильно занят. Так 
>>что ...
>>
>Собрать -- собрал, но запустить так и не смог. Как в mono, так и в
>нормальном режиме говорит, что не может проинициализировать модули.
>
Соберите  в mono режиме и сделайте приблизительно так
nm ./torque | sort | less

Второй строкой должен начинаться сегмент extraseg.
Посмотрите, есть ли там между __begin_extraseg и __end_extraseg 
какие-либо симболы?

"Can't find instalation modules" это он говорит, если не може 
проинициализировать модули.
Если в нормальном виде он их ищет там, где они указаны в конфиге, то в 
моно, в своем же бинарнике.

Опишите точнее пожалуйста

-- 
Yury Umanets,
ALT Linux Team

Re: [devel] Torque Installer

[Yury Umanets]

Stanislav Ievlev wrote:

> Yury Umanets wrote:
>
>> Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. 
>> Может кто чего скажет об потрохах? Кто смотрел?
>> Мне там конечно не все нравится, в последнее время был сильно занят. 
>> Так что ...
>
>
> Не посмотрел, но собрал и даже запустил.
>
> У нас тут проблемы с дозвоном до linux.kiev.ua - поэтому еще не все 
> посмотрели
>
> Сегодня планирую посмотреть код подробнее.
>
> Как делается консольный инсталлятор? 

Вы имеете ввиду как прогресс? Спросите у zhukov@altlinux.ru.

>
>
>>
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel



-- 
Yury Umanets,
ALT Linux Team

Re: [devel] Torque Installer

[Stanislav Ievlev]

Yury Umanets wrote:

> Stanislav Ievlev wrote:
>
>> Yury Umanets wrote:
>>
>>> Исходники лежат на http://torque.linux.kiev.ua уже несколько дней. 
>>> Может кто чего скажет об потрохах? Кто смотрел?
>>> Мне там конечно не все нравится, в последнее время был сильно занят. 
>>> Так что ...
>>
>>
>>
>> Не посмотрел, но собрал и даже запустил.
>>
>> У нас тут проблемы с дозвоном до linux.kiev.ua - поэтому еще не все 
>> посмотрели
>>
>> Сегодня планирую посмотреть код подробнее.
>>
>> Как делается консольный инсталлятор? 
>
>
> Вы имеете ввиду как прогресс? Спросите у zhukov@altlinux.ru. 

Он тоже подписан на этот список рассылки, если я не ошибаюсь.
Сообщите, пожайлуста, если это не так.

>
>
>>
>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@altlinux.ru
>> http://altlinux.ru/mailman/listinfo/devel
>
>
>
>

[devel] Torque Installer - первый взгляд

[Stanislav Ievlev]

Привет!

Теперь я посмотрел инсталлятор несколько более подробнее:
Вот возникло несколько мыслей:

1) Архитектура очень интересная, особенно касательно плагинов
2) Но вот на примере плагина welcome - как я понял графика там жестко 
прошита. То есть хотелось бы такой же легкости ив переключении с 
тектового на графический интерфейс. Это понятно сложнее, да и сделать 
виджеты одинаково для обоих режимов очень тяжело, но иначе надо как я 
понял писать две версии интерфейса для каждого модуля (см. п. 7)
3) Не совсем я также разобрался зачем нужен extraseg. Я если честно 
опасаюсь нестандартностей
4) Мне показалось, что слишком сильная привязка на gtk. Но может я не прав.
5) Инсталлятор будет постоянно усложняться. Может лучше его написать на 
C++? Современные инсталляторы от MDK и RH это многие килограммы кода в 
которых разбираться не очень просто.
6)  Есть ли какие идеи по поводу устройства загрузочной дискеты?


Повторю, что это был первый взгляд, возможно ошибочный.

7) Предлагаю посмотреть мои идеи по поводу конфигуратора (там внутри 
есть маленькая документация)
       http://linux.ru.net/~inger/Config-Dialog-b6.tar.bz2
Возможно они пригодятся или их как-то можно будет интегрировать в 
инсталлятор.
К сожалению у меня все написано на C++, но с другой стороны можно легко 
портировать на gtk (сейчас qt и newt).

Re: [devel] Torque Installer - первый взгляд

[Yury Umanets]

Stanislav Ievlev wrote:

> Привет!
>
> Теперь я посмотрел инсталлятор несколько более подробнее:
> Вот возникло несколько мыслей:
>
> 1) Архитектура очень интересная, особенно касательно плагинов 


>
> 2) Но вот на примере плагина welcome - как я понял графика там жестко 
> прошита. То есть хотелось бы такой же

Пока да, но это не недостаток архитектуры. Это мой недосмотр. Это как 
раз то о чем говорил Жуков. То есть инициализания самого плугина будет 
отдельно от инициализации самого плугина.
Вы это имели ввиду? Или вы говорите о том, что было бы неплохо весь 
внешний вид описать в xml? Тогда лучше уж заюзать мозильное ядро и 
сделать инсталяху на html :))

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

Постараемся избежать, но довольно трудно. Кроме того интерфейс это не 
очень большая часть.

>
> 3) Не совсем я также разобрался зачем нужен extraseg. Я если честно 
> опасаюсь нестандартностей 

Он нужен для того, чтобы получить один бинарник и не париться с тем куда 
положить модули, где их программа должна искать и т.д. Ну это такая тяга 
к компактности. Записал на дискетку бинарник и все :))

А на счет нестандартности, так вроде все нормально. Добавили мы одну 
секцию в elf ну и что? Это позволительно. Компилятор вон их сколько 
пихает для всякой чепухи :) В остальном - нормальный lds скрипт, для 
elf32-x86.
Мы ж можем проверять архитектуру и пихать нужный скрипт. В конце концов 
можно от него отказаться. Его вполне можно заменить dlopen-ом на свой 
бинарник, но из-за этого инсталяшка линкуется на libdl, что при 
статической линковке не дает экономию в несколько десятков килобайт.

Кроме всего прочего можно эту "фичу" вообще не использовать, если 
смущает. А можно использовать для чего-нибудь миниатюрного.

>
> 4) Мне показалось, что слишком сильная привязка на gtk. Но может я не 
> прав. 

Согласен.

Когда я уберу зависимость GUI от кода плугинов зависимость на gtk 
уменьшится. Ну а вообще, нужно ж на что-то завязываться. Нужно подумать, 
как завязаться по минимуму

>
> 5) Инсталлятор будет постоянно усложняться. Может лучше его написать 
> на C++? Современные инсталляторы от MDK и RH это многие килограммы 
> кода в которых разбираться не очень просто. 

Писал на C по нескольким причинам.
1. Инициализация быстрее.
2. Компиляция быстрее (несущественно)
3. был выбран gtk по причине легкости и GPL-ности
4. gtk-шная c++-ная реинкарнация не поспевает за c-шной
5. многие считают с++ не совсем подходящим языком для таких задач 
(несуущественно)

>
> 6)  Есть ли какие идеи по поводу устройства загрузочной дискеты? 

Этим занимает Жуков. мы с ним прорабатывали эти моменты некоторое время 
назад. У него есть опыт, да и не только. На сколько я понял, он это взял 
на себя полностью. У него не просто идеи, у него уже есть рабочий 
вариант. На сколько я знаю, он использует busybox.  Уточните у него 
пожалуйста.

>
>
>
> Повторю, что это был первый взгляд, возможно ошибочный.
>
> 7) Предлагаю посмотреть мои идеи по поводу конфигуратора (там внутри 
> есть маленькая документация)
>       http://linux.ru.net/~inger/Config-Dialog-b6.tar.bz2 

Обязательно посмотрю.

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

Посмотрим. Может какую идею сворую :))

>
> К сожалению у меня все написано на C++, но с другой стороны можно 
> легко портировать на gtk (сейчас qt и newt). 

:)) c++ не проблема.

>
Принципиальные возражения есть? Например Вы принципиально против gtk?

>
>
>
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel



-- 
Yury Umanets,
ALT Linux Team

Re: [devel] Torque Installer -первый взгляд

[Aleksey Novodvorsky]

Yury Umanets wrote:

>
>
> >
> Принципиальные возражения есть? Например Вы принципиально против gtk?

У нас здесь нет противников gtk! :-)

Rgrds, Алексей

>

Re: [devel] Torque Installer - первый взгляд

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Tue, Jan 15, 2002 at 05:29:37PM +0300, Stanislav Ievlev wrote:
> 5) Инсталлятор будет постоянно усложняться. Может лучше его написать на 
> C++? Современные инсталляторы от MDK и RH это многие килограммы кода в 
> которых разбираться не очень просто.
Может, сделать возможность смешивания языков?  Не бейте,
объясняю:

компилируемые языки (я, как чайник, принципиально разницы между
C и C++ тут не вижу):
  + быстро 
  + компактно
  - мучительно долго писать
  - еще хуже отлаживать
  
скриптовые языки:
  - толстые интерпретаторы (память, диск)
  - производительность ниже (обычно)
  + быстрее пишется (особенно создани/правка конфигов)
  + больше шансов увидеть что-то информативнее segfault
    (особенно актуально для feedback)

Вывод: создание "скелета" и относительно несложных, но требующих
производительности модулей на C/C++ _и_ разрешение более
"фаршированным" модулям (конфигурирование всего нетривиального)
пользоваться скриптовыми языками (разумеется, на той стадии,
когда уже будет доступен интерпретатор).

При этом основная часть инсталера (по продолжительности)
выполняется быстро, компактна и универсальна (как скелет и
базовые модули); основная же часть инсталера, например,
Master/Junior (уже по степени нетривиальности решаемых задач)
имеет более широкие возможности использования удобств скриптовых
языков и использует их.

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

Кстати, не вижу принципиальной невозможности использовать даже
отдельный интерпретатор (perl, ruby?) для какой-нибудь даже
_одной_ хитрой задачи, которая именно так решается наиболее
эффективно.

И еще -- таким макаром за счет некоторого дублирования кода можно
сделать режим инсталятора для машин с небольшим количеством
памяти (за счет более "простеньких" результирующих конфигов).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ http://visa.chem.univ.kiev.ua/~mike/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Torque Installer - первый взгляд

[Stanislav Ievlev]

Yury Umanets wrote:

> Stanislav Ievlev wrote:
>
>> Привет!
>>
>> Теперь я посмотрел инсталлятор несколько более подробнее:
>> Вот возникло несколько мыслей:
>>
>> 1) Архитектура очень интересная, особенно касательно плагинов 
>
>
>
>>
>> 2) Но вот на примере плагина welcome - как я понял графика там жестко 
>> прошита. То есть хотелось бы такой же
>
>
> Пока да, но это не недостаток архитектуры. Это мой недосмотр. Это как 
> раз то о чем говорил Жуков. То есть инициализания самого плугина будет 
> отдельно от инициализации самого плугина.

???

Может быть в описании каждого плугина два символа :
init_as_text
init_as_gui

>
> Вы это имели ввиду? Или вы говорите о том, что было бы неплохо весь 
> внешний вид описать в xml? Тогда лучше уж заюзать мозильное ядро и 
> сделать инсталяху на html :))
>
>> легкости ив переключении с тектового на графический интерфейс. Это 
>> понятно сложнее, да и сделать виджеты одинаково для обоих режимов 
>> очень тяжело, но иначе надо как я понял писать две версии интерфейса 
>> для каждого модуля (см. п. 7) 
>
>
> Постараемся избежать, но довольно трудно. Кроме того интерфейс это не 
> очень большая часть. 

Да, тяжело, посмотрите что мне пришлось накручивать ;))

>
>
>>
>> 3) Не совсем я также разобрался зачем нужен extraseg. Я если честно 
>> опасаюсь нестандартностей 
>
>
> Он нужен для того, чтобы получить один бинарник и не париться с тем 
> куда положить модули, где их программа должна искать и т.д. Ну это 
> такая тяга к компактности. Записал на дискетку бинарник и все :))
>
> А на счет нестандартности, так вроде все нормально. Добавили мы одну 
> секцию в elf ну и что? Это позволительно. Компилятор вон их сколько 
> пихает для всякой чепухи :) В остальном - нормальный lds скрипт, для 
> elf32-x86.
> Мы ж можем проверять архитектуру и пихать нужный скрипт. В конце 
> концов можно от него отказаться. Его вполне можно заменить dlopen-ом 
> на свой бинарник, но из-за этого инсталяшка линкуется на libdl, что 
> при статической линковке не дает экономию в несколько десятков килобайт.
>
> Кроме всего прочего можно эту "фичу" вообще не использовать, если 
> смущает. А можно использовать для чего-нибудь миниатюрного.

Я как понял это замена символов. Может кстати это позволит лучше 
застрипать плагины.

>
>>
>> 4) Мне показалось, что слишком сильная привязка на gtk. Но может я не 
>> прав. 
>
>
> Согласен.
>
> Когда я уберу зависимость GUI от кода плугинов зависимость на gtk 
> уменьшится. Ну а вообще, нужно ж на что-то завязываться. Нужно 
> подумать, как завязаться по минимуму 


>
>
>>
>> 5) Инсталлятор будет постоянно усложняться. Может лучше его написать 
>> на C++? Современные инсталляторы от MDK и RH это многие килограммы 
>> кода в которых разбираться не очень просто. 
>
>
> Писал на C по нескольким причинам.
> 1. Инициализация быстрее.
> 2. Компиляция быстрее (несущественно)
> 3. был выбран gtk по причине легкости и GPL-ности
> 4. gtk-шная c++-ная реинкарнация не поспевает за c-шной 

Мне кажется это вообще изврат - эмуляция C++ через C ;)

>
> 5. многие считают с++ не совсем подходящим языком для таких задач 
> (несуущественно) 

C++ идеален для больших проектов (как инсталлятор+конфигуратор).  Gnome 
наглядный пример что приходится накручивать для эмуляции возможностей C++.
Прикрутить обычный gtk к C++ это не проблема.

Можно оставить С на двух первых стадиях, а самую интеллектуальную часть 
сделать на C++.

>
>
>>
>> 6)  Есть ли какие идеи по поводу устройства загрузочной дискеты? 
>
>
> Этим занимает Жуков. мы с ним прорабатывали эти моменты некоторое 
> время назад. У него есть опыт, да и не только. На сколько я понял, он 
> это взял на себя полностью. У него не просто идеи, у него уже есть 
> рабочий вариант. На сколько я знаю, он использует busybox.  Уточните у 
> него пожалуйста.
>
>>
>>
>>
>> Повторю, что это был первый взгляд, возможно ошибочный.
>>
>> 7) Предлагаю посмотреть мои идеи по поводу конфигуратора (там внутри 
>> есть маленькая документация)
>>       http://linux.ru.net/~inger/Config-Dialog-b6.tar.bz2 
>
>
> Обязательно посмотрю.
>
>>
>> Возможно они пригодятся или их как-то можно будет интегрировать в 
>> инсталлятор.
>
>
> Посмотрим. Может какую идею сворую :)) 

Посмотрите на общую архитектуру  - нам надо сразу готовиться к мощной 
конфигурационной системе заранее.

>
>
>>
>> К сожалению у меня все написано на C++, но с другой стороны можно 
>> легко портировать на gtk (сейчас qt и newt). 
>
>
> :)) c++ не проблема.
>
>>
> Принципиальные возражения есть? Например Вы принципиально против gtk? 

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

>
>
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@altlinux.ru
>> http://altlinux.ru/mailman/listinfo/devel
>
>
>
>

Re: [devel] Torque Installer - первый взгляд

[Yury Umanets]

Stanislav Ievlev wrote:

> Yury Umanets wrote:
>
>> Stanislav Ievlev wrote:
>>
>>> Привет!
>>>
>>> Теперь я посмотрел инсталлятор несколько более подробнее:
>>> Вот возникло несколько мыслей:
>>>
>>> 1) Архитектура очень интересная, особенно касательно плагинов 
>>
>>
>>
>>
>>>
>>> 2) Но вот на примере плагина welcome - как я понял графика там 
>>> жестко прошита. То есть хотелось бы такой же
>>
>>
>>
>> Пока да, но это не недостаток архитектуры. Это мой недосмотр. Это как 
>> раз то о чем говорил Жуков. То есть инициализания самого плугина 
>> будет отдельно от инициализации самого плугина.
>
>
> ???

;)) отдельно от инициализации интерфейса

>
> Может быть в описании каждого плугина два символа :
> init_as_text
> init_as_gui 

Приблизительно так

>
>
>>
>> Вы это имели ввиду? Или вы говорите о том, что было бы неплохо весь 
>> внешний вид описать в xml? Тогда лучше уж заюзать мозильное ядро и 
>> сделать инсталяху на html :))
>>
>>> легкости ив переключении с тектового на графический интерфейс. Это 
>>> понятно сложнее, да и сделать виджеты одинаково для обоих режимов 
>>> очень тяжело, но иначе надо как я понял писать две версии интерфейса 
>>> для каждого модуля (см. п. 7) 
>>
>>
>>
>> Постараемся избежать, но довольно трудно. Кроме того интерфейс это не 
>> очень большая часть. 
>
>
> Да, тяжело, посмотрите что мне пришлось накручивать ;))
>
>>
>>
>>>
>>> 3) Не совсем я также разобрался зачем нужен extraseg. Я если честно 
>>> опасаюсь нестандартностей 
>>
>>
>>
>> Он нужен для того, чтобы получить один бинарник и не париться с тем 
>> куда положить модули, где их программа должна искать и т.д. Ну это 
>> такая тяга к компактности. Записал на дискетку бинарник и все :))
>>
>> А на счет нестандартности, так вроде все нормально. Добавили мы одну 
>> секцию в elf ну и что? Это позволительно. Компилятор вон их сколько 
>> пихает для всякой чепухи :) В остальном - нормальный lds скрипт, для 
>> elf32-x86.
>> Мы ж можем проверять архитектуру и пихать нужный скрипт. В конце 
>> концов можно от него отказаться. Его вполне можно заменить dlopen-ом 
>> на свой бинарник, но из-за этого инсталяшка линкуется на libdl, что 
>> при статической линковке не дает экономию в несколько десятков килобайт.
>>
>> Кроме всего прочего можно эту "фичу" вообще не использовать, если 
>> смущает. А можно использовать для чего-нибудь миниатюрного.
>
>
> Я как понял это замена символов. Может кстати это позволит лучше 
> застрипать плагины.
>
>>
>>>
>>> 4) Мне показалось, что слишком сильная привязка на gtk. Но может я 
>>> не прав. 
>>
>>
>>
>> Согласен.
>>
>> Когда я уберу зависимость GUI от кода плугинов зависимость на gtk 
>> уменьшится. Ну а вообще, нужно ж на что-то завязываться. Нужно 
>> подумать, как завязаться по минимуму 
>
>
>
>>
>>
>>>
>>> 5) Инсталлятор будет постоянно усложняться. Может лучше его написать 
>>> на C++? Современные инсталляторы от MDK и RH это многие килограммы 
>>> кода в которых разбираться не очень просто. 
>>
>>
>>
>> Писал на C по нескольким причинам.
>> 1. Инициализация быстрее.
>> 2. Компиляция быстрее (несущественно)
>> 3. был выбран gtk по причине легкости и GPL-ности
>> 4. gtk-шная c++-ная реинкарнация не поспевает за c-шной 
>
>
> Мне кажется это вообще изврат - эмуляция C++ через C ;)
>
>>
>> 5. многие считают с++ не совсем подходящим языком для таких задач 
>> (несуущественно) 
>
>
> C++ идеален для больших проектов (как инсталлятор+конфигуратор).  
> Gnome наглядный пример что приходится накручивать для эмуляции 
> возможностей C++.
> Прикрутить обычный gtk к C++ это не проблема.
>
> Можно оставить С на двух первых стадиях, а самую интеллектуальную 
> часть сделать на C++. 

:) будем посмотреть

-- 
Yury Umanets,
ALT Linux Team

Re: [devel] Torque Installer -первый взгляд

[Yury Umanets]

Aleksey Novodvorsky wrote:

>Yury Umanets wrote:
>
>>
>>Принципиальные возражения есть? Например Вы принципиально против gtk?
>>
>
>У нас здесь нет противников gtk! :-)
>
Эт хорошо :))

>
>
>Rgrds, Алексей
>
>
>
>_______________________________________________
>Devel mailing list
>Devel@altlinux.ru
>http://altlinux.ru/mailman/listinfo/devel
>


-- 
Yury Umanets,
ALT Linux Team

Re: [devel] Torque Installer

[Alexander Bokovoy]

On Tue, Jan 15, 2002 at 01:02:55PM +0200, Yury Umanets wrote:
> "Can't find instalation modules" это он говорит, если не може 
> проинициализировать модули.
> Если в нормальном виде он их ищет там, где они указаны в конфиге, то в 
> моно, в своем же бинарнике.
> 
> Опишите точнее пожалуйста
Пока не могу -- это дома. Может быть на "выходных" еще раз посмотрю.

p.s. Господа, удаляйте ненужные части сообщений, на которые отвечаете.
В противном случае письма очень сложно читать при катастрофической
нехватке времени.
-- 
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
  `Senior software developer and analyst for SaM-Solutions Ltd.`
---
Nov 21 20:58:58 alconost kernel: VFS: Busy inodes after unmount. 
		    Self-destruct in 5 seconds.  Have a nice day...

[devel] Re: Torque Installer - первый взгляд

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]

Hello Stanislav,

On Tue, Jan 15, 2002 at 07:54:36PM +0300, Stanislav Ievlev wrote:
>
> Yury Umanets wrote:
> 
> >Stanislav Ievlev wrote:
> >
> >>Привет!
> >>
> >>Теперь я посмотрел инсталлятор несколько более подробнее:
> >>Вот возникло несколько мыслей:
> >>
> >>1) Архитектура очень интересная, особенно касательно плагинов 
> >
> >
> >
> >>
> >>2) Но вот на примере плагина welcome - как я понял графика там жестко 
> >>прошита. То есть хотелось бы такой же
> >
> >
> >Пока да, но это не недостаток архитектуры. Это мой недосмотр. Это как 
> >раз то о чем говорил Жуков. То есть инициализания самого плугина будет 
> >отдельно от инициализации самого плугина.
> 
> ???
> 
> Может быть в описании каждого плугина два символа :
> init_as_text
> init_as_gui

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

> >Вы это имели ввиду? Или вы говорите о том, что было бы неплохо весь 
> >внешний вид описать в xml? Тогда лучше уж заюзать мозильное ядро и 
> >сделать инсталяху на html :))

Mozilla, конечно, перебор. Но насчет XML стоит подумать. В случае
инсталлятора у нас имеется ограниченный набор управляющих элементов --
статический текст, поля ввода, списки, галки, максимум --
деревья. Несложный набор layout'ных примитивов, хватит одной таблицы
либо даже вертикальных/горизонтальных разбиений. Или даже только
вертикальных отбивок в стиле <hr>.
Для GTK эти описания теоретически можно транслировать в glade с
помощью XSLT. Для ncurses -- придется исхитряться.

> >
> >>легкости ив переключении с тектового на графический интерфейс. Это 
> >>понятно сложнее, да и сделать виджеты одинаково для обоих режимов 
> >>очень тяжело, но иначе надо как я понял писать две версии интерфейса 
> >>для каждого модуля (см. п. 7) 
> >
> >
> >Постараемся избежать, но довольно трудно. Кроме того интерфейс это не 
> >очень большая часть. 
> 
> Да, тяжело, посмотрите что мне пришлось накручивать ;))
> 
> >
> >
> >>
> >>3) Не совсем я также разобрался зачем нужен extraseg. Я если честно 
> >>опасаюсь нестандартностей 
> >
> >
> >Он нужен для того, чтобы получить один бинарник и не париться с тем 
> >куда положить модули, где их программа должна искать и т.д. Ну это 
> >такая тяга к компактности. Записал на дискетку бинарник и все :))
> >
> >А на счет нестандартности, так вроде все нормально. Добавили мы одну 
> >секцию в elf ну и что? Это позволительно. Компилятор вон их сколько 
> >пихает для всякой чепухи :) В остальном - нормальный lds скрипт, для 
> >elf32-x86.
> >Мы ж можем проверять архитектуру и пихать нужный скрипт. В конце 
> >концов можно от него отказаться. Его вполне можно заменить dlopen-ом 
> >на свой бинарник, но из-за этого инсталяшка линкуется на libdl, что 
> >при статической линковке не дает экономию в несколько десятков килобайт.
> >
> >Кроме всего прочего можно эту "фичу" вообще не использовать, если 
> >смущает. А можно использовать для чего-нибудь миниатюрного.
> 
> Я как понял это замена символов. Может кстати это позволит лучше 
> застрипать плагины.
> 
> >
> >>
> >>4) Мне показалось, что слишком сильная привязка на gtk. Но может я не 
> >>прав. 
> >
> >
> >Согласен.
> >
> >Когда я уберу зависимость GUI от кода плугинов зависимость на gtk 
> >уменьшится. Ну а вообще, нужно ж на что-то завязываться. Нужно 
> >подумать, как завязаться по минимуму 
> 
> 
> >
> >
> >>
> >>5) Инсталлятор будет постоянно усложняться. Может лучше его написать 
> >>на C++? Современные инсталляторы от MDK и RH это многие килограммы 
> >>кода в которых разбираться не очень просто. 
> >
> >
> >Писал на C по нескольким причинам.
> >1. Инициализация быстрее.
> >2. Компиляция быстрее (несущественно)
> >3. был выбран gtk по причине легкости и GPL-ности
> >4. gtk-шная c++-ная реинкарнация не поспевает за c-шной 

Насколько я в курсе, за стабильной -- поспевает.

> Мне кажется это вообще изврат - эмуляция C++ через C ;)

Зато ABI libgtk+.so не зависит от версии компилятора, флагов и т.п.
Объектно-ориентированное программирование не обязательно требует
объектно-ориентированного языка :)

> 
> >
> >5. многие считают с++ не совсем подходящим языком для таких задач 
> >(несуущественно) 
> 
> C++ идеален для больших проектов (как инсталлятор+конфигуратор).  Gnome 
> наглядный пример что приходится накручивать для эмуляции возможностей C++.
> Прикрутить обычный gtk к C++ это не проблема.
> 
> Можно оставить С на двух первых стадиях, а самую интеллектуальную часть 
> сделать на C++.

Тогда лучше был бы Python. И проще, и красивее, и с потенциальными
frontend'ами интегрируется. Даже не сильно накладно могло бы
получиться, особенно если скомпилировать в .pyo и выкинуть исходники.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Going to church does not make a person religious, nor does going to school
make a person educated, any more than going to a garage makes a person a car.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]