Zmei wrote:

>АБ> Вряд ли мы сможем сделать какой-то прорыв в алгоритмической реализации
>АБ> ядра.
>Да ну... Конечно, не понятно ударение в фразе то ли на "мы сможем", то
>ли "сделать какой-то прорыв". И если первое действительно "вряд ли",
>то второе очень даже возможно.
>
>
И какой прорыв возможен?

>АБ> То есть, если сейчас ядро напрямую не
>АБ> поддерживает многозадачность (параллелизм), не поддерживает механизм
>АБ> исключений, не поддерживает распределение памяти с автоматической
>АБ> проверкой результата, не поддерживает классы, не поддерживает
>АБ> автоматический контроль диапазона чисел, а делает все это только
>АБ> посредством дополнительных, специально написанных функций, то можно все

>АБ> это одновременно и элегантно получить, переписав его на языке
>АБ> программирования Ada95.
>Почему именно на Ada95?
>
>
Самый лучший компилируемый язык...

>АБ> Просто берем и реализуем на Ada те части,
>АБ> которые раньше были сделаны на Cи, но очень некрасиво и нелогично (как
>АБ> вспомогатальные функции).
>Особено весело становится тогда, когда представляешь 5.5 млн. строк
>кода, из которых надо выбрать те места, которые некрасиво написаны на
>Cи, и их красиво переписать на Ada.
>
Откуда такое число? Подсчитать проще так: скомпилировать ядро, а потом
посмотреть, какие файлы с расширением .h или .c для этого используются
(с помощью find -atime). Можете подсчитать...

>АБ> Многозадачность встроена в Ada, так что
>АБ> специально делать ничего не надо, проверка диапазона и проверка памяти
>АБ> тоже, исключения есть, классы тоже. Вот с этого и начать, что уже есть.
>АБ> Сделать костяк на Ada, который можно назвать Microkernel.
>На самом деле написание добротной архитектуры микроядра отнюдь не
>тривиальная задача. ...даже на Ada...
>
>
А кто сказал что тривиальная?

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

>АБ> нет. Это была бы неоценимая польза для русскоязычного ПО.
>Кстати, хороший вопрос. А документация по Ada где-нибудь вообще
>есть(на любом языке)? И можно ли почитать?
>
>
http://faqs.org.ru/progr/other_l/adafaq.htm
http://www.pegasoft.ca/homes/AdaLinuxPDF.zip
http://www.gnuada.org/alt.html
http://www.gnat.com
http://www.adahome.com
http://adalab.nm.ru

>АБ> Далее. Если ядро было бы на языке Ada95, то интерфейс ядра можно было бы
>
>АБ> сделать "адовский", что побуждало бы разработчиков ПО с целью наибольшей
>
>АБ> эффективности создавать новое ПО на языке Ada.
>
>АБ> Создана же целая ОС - AdaOS.
>И как, пишут под AdaOS ПО?
>
>
Наверное...

>
>
>>>АБ> Это не так сложно, как кажется. Конечно, есть разные принципы
>>>АБ> разработки. Есть одно, другое, третье. Но, скажите, разве нельзя,
>>>АБ> скажем, обойтись двумя графическими интерфейсами?
>>>
>>>
>
>
>
>>Нет нельзя. Уже не получится...
>>
>>
>
>АБ> Почему?
>:)) Существует множество пользователей и разработчиков привыкших к
>нескольким графическим интерфейсам. Поэтому это вызовет праведное
>негодование тех, чей любимый интерфейс не будет использоваться дальше.
>
>
Ну и пусть вызовет.. Не поддерживаются же многие библиотеки, которые уже
исчерпали свои возможности. Если им так нужны эти интерфейсы - пусть
качают из Сети. Из-за процента пользователей не стоит захламлять
дистрибутив...

>
>
>>>Да и конкуренция порождает развитие. Или нет?
>>>
>>>
>
>АБ> Нам надо выбрать из всего то, что достаточно для наших задач. Зачем нам

>АБ> много?
>Дабы породить конкуренцию. Это нормальный механизм рынка. Вопрос
>"Зачем нам много?" ведет к уменьшению роли обратной связи в разработке
>программного обеспечения. В конечном итоге, мы можем получить
>разомкнутую систему регулирования, выражаясь в терминах ТАУ, а это
>ведет к уменьшению точности управляемого параметра. :))
>
>
Соревнуются-то пусть, но МЫ будет использовать только лучшее, а не все.

>АБ> Если, скажем, QT есть, то он, конечно, красив. Но ведь
>АБ> возможности gtk ничуть не меньше. А QT ведь не распространяется по GPL.
>А BSD тоже не распространяются под GPL. И всеми любиый Apache не
>распространияется под GPL. И при этом никто и не подумает назвать эти
>продукты несвободными. Это просто другое понимание свободы.
>Использование или неиспользование GPL далеко не повод выносить оценку
>проектам. Imho это не лучшая политика сообщества FSF, при всем моем
>уважении к Столману...
>
>
>
Ошибочка вышла. Я имел в виду, конечно, не конкретные лицензии, а то,
что они позволяют бесплатное распространение и модификацию.

>>>Как сказал бы дюдюшка
>>>Билл: разве нельзя обойтись двымя операционками, например, XP и Server
>>>2003?
>>>
>>>
>
>АБ> Да, он бы явно забыл о Linux... Но ведь gtk и tk мультиплатформенные!
>АБ> Разрабатывай для любой ОС!
>На самом деле смысл был другой: кому-то нравится один инструмент,
>кому-то другой, и таких инструментов десять-двадцать, то это далеко не
>повод отбирать у всех привычные инструменты, чтобы сократить число
>оных до двух-трех, ибо "зачем нам больше".
>Если инструмент создан, но не используется - он сам умрет, но если он
>используется, значит - он нужен. Простая логика.
>
>
Вряд ли он умрет. Для него тоже найдутся последователи. Так же как
расплодилось и количество видов спорта. Никчему столько. Реально
полезными являются только единицы. Остальные лишь постольку-поскольку.
Они не вмещают функциональности более мощных.

>
>
>>>АБ> Один для компилируемых
>>>АБ> языков, второй - для интерпретируемых. Например, gtk2 и tk?
>>>И как ты собираешься это делать? Точнее какими способами?
>>>
>>>
>
>АБ> Дать рекомендации писать только для этих GUI (а если кому-то эти GUI не

>АБ> понравятся - предложить их улучшить), включать в дистрибутив по
>АБ> возможности "правильные" интерфейсы.
>Данная проблема решалась проще. Когда нексолько компаний (Digital, HP,
>IBM и другие, сейчас не вспомню) объединились в Open Software
>Foundation(OSF). И основной целью OSF стала разработка ОС, которая
>могла составить конкуренцию разрабатывающейся в то же время SunOS
>(на основе SVR4), и в то же время была свободна от лизензионных
>ограничений AT&T. OSF распространила среди своих членов "Запрос на
>технологии"(в оригинале, могу ошибится, "Request for Technology") и
>выбрала из полученных технологий лучшие по ряду параметров. Кстати
>сказать, после этого OSF выпустила небезизвестный Motif, а потом уже
>OSF/1.
>
>АБ> Да, про Assembler забыл. Но он используется редко (только для ядра и
>АБ> утилит). Мы же говорим больше про приложения. И еще ошибка: PHP - не
>АБ> универсальный язык.
>Assembler не заменим и для прошивки микроконтроллеров, ПЗУ и вообще
>аппаратных средств.
>Но все равно набор языков достаточно спорен...
>
>АБ> В России должен был властвовать царь. Но теперь, в силу исторических и
>АБ> др. причин, сложно сказать какой из политических режимов лучше. Конечно,
>
>АБ> в идеале, единоличная власть одного человека.
>
>Ваши идеи, батенька, как в политике, так и в программировании очень
>спорны.
>
Возможно, для кого-то и спорны... Люди разные...

>
>
>>>Т.е. ты хочешь реализовать подобную схему: (а) собирается ядро и
>>>минимально необходимый набор приложений, т.е. даже еще без X Window
>>>System,
>>>
>>>
>
>АБ> Ну, собраны они должны быть еще разработчиком дистрибутива, хотя,
>АБ> впрочем, одним из заключительных этапов установки можно предусмотреть
>АБ> самосбор всех используемых пакетов. А установка уже графическая! Если
>АБ> пользователь не поставит XWindows - пусть не ставит, но предупреждение
>АБ> об неустановленной графической среде будет выведено.
>
>АБ> А чем .deb .rpm xfs или NTFS лучше? И какое название является, например,
>
>АБ> более удобочитаемым?
>Из вышеперечисленых - deb. :))
>
Для кого как...

>А что касаемо названия, тот же нелюбимый тобой Debian запоминается
>лучше, нежели FTS. Попробуй кому-нибудь сказать FTSLinux, и через день
>спросить "как я сказал?", я уверен 9 из 10 или не ответят, или
>ошибутся. Но, в принципе, не так уж это и влияет на работоспособность
>системы... Кстати, а что ж оно означает? Или это просто ты словарь в
>призвольных местах открывал - вот и получилось...
>
А по ссылочке на http://kill9.h1.ru сложно пройти? Там сказано: Russian
Linux Distribution for (F)undamental (T)echnical (S)cience. А то, что
дистрибутив назван каким-то иностранным именем, для нас не легче.

>
>АБ> Но вот кто-то хотел привести описание sysinstall.
>Забей... это я так брякнул... немножко другое имел ввиду...
>
Нет, но все-таки, камень как-то не хочется бросать! Чем он лучше,
скажем, dpkg?

>
>АБ> Еще
>АБ> функция: иногда демон отслеживает (с помощью find) давно неиспользуемые

>АБ> файлы пакета и предлагает и удалить.
>А если я дату на год вперед случайно отодвинул, он мне и ядро
>предложит удалить? Незнаю-незнаю подобная функция не очень-то и
>полезна. Сильно раздражать будет.
>
Так тогда можно СЛУЧАЙНО и винчестер форматнуть! Если время было
случайно изменено, то его ведь несложно и вернуть обратно! Если демон
будет предлагать что-то удалять, то можно опционально от любого удаления
отказаться и он больше не будет спрашивать, пока снова не включить эту
опцию. А ядро не предложит удалить, т.к. оно есть критическая программа,
которая входит в список неудаляемых файлов демона.

>
>
>
>>>А как будет с реализацией подобной схемы?
>>>
>>>
>
>АБ> Еще пока неясно. А какие могут быть проблемы?
>Я спрашивал не про проблемы, а про идеи реализации...
>Не принимай уж сразу все так в штыки.
>
>
>
>
Да вроде как эти идеи уже описаны. Что еще непонятно?

>
>

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Александр Сергеевич Гордиенко wrote:

>>>1) некрасивое название;
>>>
>>>На вкус и цвет... Мне кстати нравится.
>>>
>>>
>>>
>>А словом "дебил" не попахивает. Или это слово тоже нравится?
>>
>>
>
>Ты первый, кто сказал о таких ассоциациях, ранее я такого не слышал... Это
>действительно свежо :-)
>
>
Вот так... Можно еще привести ассоциацию со словами "дебри" и "дебош".

>
>
>>>2) ориентация на текстовый режим работы;
>>>
>>>Только при инсталляции.
>>>
>>>
>>>
>>Вот именно. И при установке пакетов.
>>
>>
>
>А тут ты уже гонишь :-)
>
>Debian Configuration
> ,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,/= [?]
Configuring Debconf /-TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,g'
> G' Пакеты, использущие debconf для своей настройки, обладают единым
G'
> G' интерфейсом. Вы можете выбрать наиболее подходящий.
G'
> G'
G'
> G' Диалоговая оболочка - полноэкранная, в то время как "строка ввода"
G'
> G' использует более традиционный простой текстовый интерфейс, а Gnome -
G'
> G' современный X интерфейс. Режим редактора позволит вам задавать
G'
> G' настройки в вашем любимом редакторе. Неинтерактивный режим
G'
> G' избавит вас от необходимости отвечать на какие-либо вопросы.
G'
> G'
G'
> G' Какой интерфейс нужно использовать для настройки пакетов?
G'
> G'
G'
> G' диалог
G'
> G' строка ввода
G'
> G' Gnome
G'
> G' редактор
G'
> G' неинтерактивный
G'
> G'
G'
> G'
G'
> G' <Ok> <Cancel>
G'
> G'
G'
> ,,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,TH,...
>
>Строчку Gnome видишь? Это оно...
>
>
Я же говорю - ориентация. То есть что в Debian предпочтительнее.
Понятно, что сейчас почти для любой более-менее используемой консольной
программы "наклепали" GUI.

>
>
>>>4) отсутствие некоторых необходимых пакетов;
>>>
>>>Есть такое, в основном по лицензионным проблеммам, но
>>>
>>>
>>www.apt-get.org спасает
>>
>>
>>>даже от этого :-)
>>>
>>>
>>>
>>И даже не по лицензионным. Трудно универсальному дистр. соперничать со
>>специализированным.
>>
>>
>
>Дополни, нет никаких проблем вот пример: http://ftp.45.free.net/debian.
>Лично у меня оттуда tetex 2 какой-то, шрифты pscyr для того же tetex и многое
>другое.
>Это же все можно зарезать на доп болвань и при инсталляции проиндексировать
>её наряду с остальными, тем самым добившись, что некоторые проги будут
>ставится с твоего диска, а не с оригинальных, т.е. перекрыть некоторые
>пакеты. Например есть у меня где-то 3.0r1 с KDE2 и KDE3, ставится KDE3 и все
>довольны.
>
>
LaTeX или KDE не являются специализированными пакетами... Я хочу
сказать, что и Debian не объять необъятное, не угнаться за всем. А то,
что он разростается как снежный ком, еще вообще не говорит о том, что
это хорошо. Зачем мне иметь и покупать десятки дисков, когда я могу для
своих задач ограничиться единицами и знаю, что мне пока хватит? А когда
не хватит, то все равно те, что были бы на этих дисках Debian, уже
устареют. И придется снова качать из Сети.

>
>
>>>5) упрощенная система разрешения зависимостей пакетов;
>>>
>>>Ну это ты загнул :-), ты знаешь, сколько типов зависимостей в Debian?
>>>
>>>
>>>
>>И что? Если, скажем, мне из другого пакета нужен всего один файл, то
>>
>>
>
>И ты конечно, круче майнтейнера и автора проги, которые на этом деле собаку
>съели, чтобы решить, что этот файл будет работать без того окружения, которое
>содержится в пакете и без той настройки, которую пакет обеспечивает?
>
>
Я не круче, но работать будет. Потому как если я некоторые бинарные
пакеты не хочу в принципе использовать, то могу изначально и не
устанавливать. И если, например, у меня нет звуковой карты, то не нужно
устанавливать никакие файлы для работы со звуками.

>
>
>>что: я должен ставить весь многомегабайтный пакет? И вообще, даже в
>>
>>
>
>Не, ты не в теории, а в практике... Приведи пример... Только не для tex, CTAN
>рулит.
>
>
Примеров много. Помню, один возмущался, что какой-то пакет kde* требовал
kdegames, хотя пользователь совсем не нуждался в играх. Примеров много.
Техника сборки пакетов неудовлетворительна...

>
>
>>Debian никто не спрашивает, какая, полная ли функциональность
>>пакета мне
>>нужна или его часть.
>>
>>
>
>$ dpkg -l tetex*
>ii tetex-base 2.0.2-1 basic teTeX library files
>ii tetex-bin 2.0.2-1 teTeX binary files
>un tetex-dev <none> (no description available)
>ii tetex-doc 2.0.2-1 teTeX documentation
>pn tetex-eurosym <none> (no description available)
>ii tetex-extra 2.0.2-1 extra teTeX library files
>un tetex-french <none> (no description available)
>un tetex-lib <none> (no description available)
>un tetex-nonfree <none> (no description available)
>pn tetex-src <none> (no description available)
>
>Приводить kde не буду, скажу только, что пакетов начинающихся с kde - 95 а
>сколько еще либ и прочего.
>
>$ dpkg -l cyrus*
>pn cyrus-admin <none> (no description available)
>rc cyrus-common 1.5.19-9.1 CMU Cyrus mail system (common files)
>pn cyrus-dev <none> (no description available)
>rc cyrus-imapd 1.5.19-9.1 CMU Cyrus mail system (IMAP support)
>pn cyrus-nntp <none> (no description available)
>rc cyrus-pop3d 1.5.19-9.1 CMU Cyrus mail system (POP3 support)
>
>
>
А зачем мне, например, весь пакет tetex-doc?

>>Есть, конечно, настройка пакета после
>>установки, но
>>это не то. Что, мы будем вначале ставить файлы пакета, а потом сразу
>>удалять (лишние)? Лишняя работа...
>>
>>
>
>Точно :-) и зачем её делать? Сейчас найти новый винт на 10 гб проблема,
>поэтому, на мой взгляд это не актуально.
>
>
>
Как сказать... Кому-то и не проблема... А кто-то еще до сих пор мучится
в институтах (г. Казань) на Intel 80386 процессорах и менее, чем в 1 Гб
винчестером.

>>>6) не очень развитая программа установки пакетов;
>>>
>>>Ээээ... Ты её с чем сравниваешь? И что имеешь в виду под не
>>>
>>>
>>очень развитой?
>>
>>
>>Вскоре прояснится.
>>
>>
>
>Подождем... Правда мне кажется, что ты один все это не поднимешь.
>
Наверное, если все только будут критиковать... Но думаю, что мои идеи
кто-нибудь да возьмет на вооружение.

>
>
>
>>>7) отсутствие иерархичности в структуре дистрибутива (по
>>>
>>>
>>крайней мере, в
>>
>>
>>>версии 3.0r0);
>>>
>>>Есть иерархичность, но не файловая... При том количестве
>>>
>>>
>>файлов, который есть
>>
>>
>>>в дебиане и такой системе управления пакетами, это не нужно.
>>>
>>>
>>А если я захочу просто просмотреть диск в файл-менеджере? Просто
>>
>>
>
>А я не хочу его вставлять в сидюк... Или как у меня на работе, на проксе
>просто нет cdrom...
>
Нет дак нет... Может, и компьютера скоро не будет... Я что, должен по
воздуху дистрибутив распространять?

>
>
>
>>покопаться в диске? Почему я должен видеть только алфавитный порядок
>>файлов? А. Колотов где-то здесь на форуме говорит, что иерархию не
>>сделали потому, что можно эту иерархию сделать по многим критериям. Но
>>ведь в Linux есть ссылки. Пожалуйста, делайте на файловом уровне! Если
>>
>>
>
>Да, а вдруг тебе захочется посмотреть под виндой (нет мягких ссылок) или ты
>захотел скопировать cdrom на винт и получил 2Гб вместо 700Мб (если там были
>жесткие) или у тебя основной носитель, с которого ставятся пакеты не cdrom,
а
>сеть как у меня, легко ли будет тебе бродить :-).
>
>
>
"Брожение" гарантируется только под Linux. Хотя мне так кажется, что
файловая система iso9660 предоставляет ссылки и для Windows. Никаких
жестких ссылок не будет! А для работы по сети несложно установить SAMBA
или NFS. Тот же play.sh будет запускаться под Windows?

>
>
>>>8) менее популярен, чем Red Hat-дистрибутивы;
>>>
>>>Возможно.
>>>
>>>
>>>
>>И это главное: таду-даду-да :)). Заходишь на сайт разработчика, а там
>>только .tar.gz, .src.rpm и .rpm. А .deb редко. Почему я должен
>>
>>
>
>Rpm для RedHat не равен rpm для Mandrake...
>
Конечно, но для этого в постфиксе пакета в последнее время пишут
соответственно rh или mdk.

>И для какого дистра готовился
>rpm? А когда есть deb, то подобных вопросов не возникает.
>
>
>
Не возникает. Но мало таких пакетов на сайтах разработчиков...

>>все время
>>обращаться к www.debian.org, если мне вдруг захотелось скачать
>>пакет от
>>первоисточника?
>>
>>
>
>Это спор беспредметный, т.к. любой пакет попадающий в дистриб (неважно
>какой), должен быть проверен на соответствие policy и т.д.
>
>
>
Я говорю о том, что

>
>
>>>9) отсутствие мощной русскоязычной поддержки;
>>>
>>>debian-russi***@l*****.org - очень мощьная, очень
>>>
>>>
>>русская поддержка.
>>
>>
>>И все?? Только одна ссылка?
>>
>>
>
>Мне этого хватает, правдо это я :-)
>
>
>
>>>10) медленное обновление дистрибутива по так называемым "нестабильным"
>>>пакетам.
>>>
>>>Пять-шесть необходимых тебе пакетов можно и руками пересобрать, а ещё
>>>вероятнее, что они есть в backport'ах
>>>
>>>
>>>
>>>
>>>
>>Когда я взял Debian 3.0r0, то ожидал там увидеть kde3. Но не увидел.
>>Что, KDE 3, по мнению разработчиков Debian, так сильно глючит (лично у
>>меня глючит (с закрытием) только konqueror)? Могли бы уж тогда
>>придумать
>>
>>
>
>Просто Debian 3.0r0 вышел до kde3.
>
Неужели? А ASPLinux 7.3, вышедший почти в то же время, уже его имел...
Просто опять разработчики Debian протормозили...

>Это во первых, а во вторых, кто же будет
>перепаковывать официальный, стабильный релиз?
>
>
>
В каком смысле перепаковывать?

>>раздел типа "supernonstable" и помещать в него популярные, но не очень
>>стабильные пакеты. Все равно ведь много дисков. А качать ок. 100 Мбайт
>>пакетов (KDE), которые уже давно на сайте разработчика, а в дисковом
>>варианте Debian еще нет, как то не совсем хочется.
>>
>>PS. Видимо, этот спор о преимуществах и недостатках различных
>>дистрибутивов может длиться бесконечно. Спешу вас обрадовать,
>>что новый
>>дистриб. не будет базироваться ни на каком известном дистрибутиве, а
>>будет вбирать в себя их достоинства и отметать недостатки. (Идеально
>>написано...)
>>
>>
>
>У меня конечно есть здоровые сомнения по этому поводу, но тем не менее, желаю
>удачи.
>
>
>
>
Ну вот, хоть один человек пожелал удачи. И на том спасибо...

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Kolotov Alexandr wrote:

>АБ> Не думаю. В солидных фирмах тратятся миллионы долларов только на
>АБ> составление спецификации для программного продукта. Продумывается все,
>АБ> вплоть до мельчайших деталей. А уж потом наступает этап реализации. Если
>АБ> вы думаете, что и мы так не можем, то глубоко ошибаетесь. Да, это
>АБ> сложнее, чем просто - наобум - написание кода, с его бесконечным
>АБ> тестированием, как поступает большинство программистов. Надо именно
>АБ> ввести в среду Open-Source программистов определенные критерии,
>АБ> определенные требования к качеству результирующего кода и его
>АБ> сопровождению. Пока мы будем бессистемно "клепать" код, то так и
>АБ> останемся с глюками и нереализованными возможностями. А документация не
>АБ> есть второстепенное. Вспомните хотя бы наши ГОСТы на программное
>АБ> обеспечение. У них, за рубежом, - да. Нужно быстрее создать код. Нам же
>АБ> торопиться некуда. Можно делать на совесть.
>Артем, это уже тогда не будет "Just for fun", это будет "for you", т.е.
>раз это не для меня как разработчика, а для тебя как пользователя,
>
Стоп. Мы это создаем в первую очередь для себя: и программы, и GUI,
чтобы самим же проще настраивать и не запоминать ненужные
последовательности команд. Понятно, что на какого-то дядю я не захочу
бесплатно работать. Но я уже говорил, что сама идея Linux, то, что нам и
так все бесплатно досталось, побуждает к бесплатному созданию ПО. Иначе
эачем бы это было Линусу. Если же так не думают другие, - те, кто
пользуется Linux, - то это значит, что им не близка идея свободного ПО,
а сами они видят в Linux еще одну обычную операционку типа Windows. И
здесь надо отметить нехорошие тенденции в мире Linux создавать
коммерческие дистрибутивы. Например, типа Caldera или серверные
дистрибутивы от RedHat или altlinux. Такая позиция уже не может
называться линуксовой, точно так же, как (уже было сказано на форуме)
ядро Linux, переписанное на другом языке программирования, не должно
называться ядром Linux'а. И создание коммерческих приложений для Linux
не может называться "линуксовым делом". Конечно, эти вопросы спорные.
Само понятие: коммерция и зарабатываение денег не совместимо с понятием
Линукс. Скорее, можно говорить об определенной уступке, когда
коммерческое ПО ставится на Linux.

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

Но вот когда, скажем, я захочу выложить свою работающую программу на
сайт, то мне - это следует признать - придется потрудиться. Мне придется
учесть по возможности все варианты условных переходов, которые я раньше
не использовал по причине и так нормальной работоспособности, но которые
всегда держал в уме и старался не использовать на практике. Если же я не
захочу таким образом расширить функциональность программы и избежать
многих глюков, то я должен все эти условные нереализованные переходы
отразить в документации и сказать, чтобы и пользователь имел это в виду.
Что, конечно же, резко снижает надежность программы, если пользователь
об этом забудет. Если же я захочу доработать таким образом программу, то
документацию мне все равно придется писать по крайней мере: 1) по
области применения; 2) по возможностям; 3) по ключам программы; 4) по
нереализованным возможностям.

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

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

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

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

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

>
>АБ> Понятно, что куда веселей создавать код, чем потом его описывать. Но,
>АБ> поверьте, во второй части ничуть не меньше творчества. Если описание
>АБ> будет не совсем логичным, то нормальный программист рекурсивно подправит
>АБ> свой же код.
>Хм, ну не знаю... может на очередном витке спирали и подправит, а так
>лучше пока забьет на документацию...
>
И зря...

>
>АБ> А то, что это даже как-то просто нелепо выпрашивать Биллом Гейтсом у
>АБ> университетов ставить именно Windows. Просто даже противно становится,
>АБ> когда понимаешь, что эта красивая по интерфейсу ОС создана не для людей,
>АБ> а для наживания денег и славы.
>Дык, это мир такой... Видишь красивую машину на улице - она сделана для
>денег; ешь вкуснейший "магазинский" торт - он тоже для денег;
>используешь ASPLinux - не поверишь, но он тоже для денег...
>
Не спорю, но разработчики ASPLinux ничего не имеют от того, что кто-то
скачивает с их сайта три диска пакетов.

> Человеку
>свойственно стремление обогатиться... Просто для кого-то это обогащение
>духовное, а для кого-то материальное...
>
А для кого-то и то, и другое :))

>
>АБ> Потом увидите. Долго объяснять... Ладно, кратко: вплоть до каждого файла
>АБ> разрешение зависимостей (этого еще не реализовано ни Linux, ни в
>АБ> Windows); ставить только то, что нужно для пользователя с запросом от
>АБ> него. Впрочем, эта идея близка к идее установки OpenOffice.org или новых
>АБ> установщиков для Windows. Автоматическая доустановка (или установка)
>АБ> пакетов, а также динамическая распаковка при первом обращении к файлу из
>АБ> них. Еще?..
>т.е. что-то типа демона пакетного менеджера, который следит: если
>какая-то программа требует файла из пакета, которого нет в системе, то
>демон его устанавливает, так? Что ж, действительно интересное развитие...
>
>АБ> Они такие же люди, как и мы. И понимают "графически интуитивный интерфейс".
>Нифига. Сходу никакая домохозяйка не может понять WIMP интерфейс,
>проверено. Все равно приходится много объяснять. Даже если внизу
>подсказки появляются...
>
Смотря какие подсказки... Сходу и младенец не может понять... Но если
хоть с одной программой она поработала, то хоть знает, где меню. А через
него в принципе все можно сделать. По крайней мере унифицированный для
каждой программы интерфейс. А так бы надо знать для каждой программы
свои команды. Их ей, да, не упомнить...

> Для понятия "интуитивного интерфейса" у человека
>должна быть развита эта "интуиция", ну и еще немного абстрактного
>мышления...
>
>АБ> Об этом уже сказано на ftslinux.h11.ru/index.html. Если они накладывают
>АБ> патчи на свои пакеты, а о других дистрибутивах забывают, то получаем как
>АБ> бы уже и не свободное ПО. Не свободное в смысле распространения патчей.
>дык, патчи-то свободны для скачивания из Инета, просто их нужно
>искать...
>
Вот именно. Не у всех ведь бесплатный Интернет...

>АБ> Здесь уже пахнет конкуренцией. Технология должна быть следующей: патчи
>АБ> бывают двух видов. 1) для исправления ошибок или улучшения
>АБ> функциональности или 2) чтобы менеджер пакетов лучше работал с таким
>АБ> пакетом. Так вот, пожалуйста, применяйте патчи второго типа, если
>АБ> система управления пакетов у вас другая, чем это предусмотрено в
>АБ> исходном пакете. А патчи первого типа должны быть отправлены автору.
>А если автор их не хочет включать в стандартный пакет?
>АБ> Или
>АБ> выложены на всеобщее обозрение на каком-то сайте.
>Это есть... см. выше...
>АБ> А включать их в свой
>АБ> бинарный пакет, который к тому же называется еще и так же, как и в
>АБ> других дистрибутивах - нет, увольте.
>Дык, для этого в названиях пакетов есть префиксы: rh, asp, alt, mdk и
>даже fts ;)
>
>
>
Префиксы то есть, но вот как определить, чем этот пакет отдичается от
такого же, но с другим префиксом?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Alexander S. Gordienko wrote:

>On Fri, Feb 06, 2004 at 07:22:30PM +0300, Артём Бельтюгов wrote:
>
>
>>>>Посмотри play.sh. Я могу посмотреть, побегать, почитать и тут
>>>>же поставить,
>>>>все каталогизировано и т.д. и т.п., а что ты можешь понять по
>>>>названию пакета
>>>>в файловом менеджере?
>>>>
>>>>
>>>>
>>По названию пакета, верно, я понять много не могу, но если этот пакет
>>лежит, например, в каталоге office/printing/cups или, например, в
>>programming/java/jplot, да еще с ним вместе лежит и документация, да еще
>>и скриншоты, то уже многое проясняется и без установки пакета.
>>
>>
>
>а поставить оттуда с соблюдением всех зависимостей? а увидеть
>зависимости пакета?
>
>
Для стандартного менеджера RPM это, да, проблема. Но есть и расширения
RPM типа autorpm, autoupdate, InDependence, yum, yup, rpmfind, rpmwiz,
up2date. В принципе, несложно написать и скрипт для этого. А все пакеты
можно собрать с помощью ссылок в один каталог и оттуда устанавливать.
Даже если они находятся на разных дисках, как в Debian. Впрочем, и
система dpkg, и rpm не совсем удобны. Увидеть зависимости пакета - rpmgraph.

>
>
>>>Блин сукс, опять забыл про то, что subscribe не пропускает вложения, вот этот
>>>paly.sh...
>>>
>>>
>>>
>>А что это за двоичный код? Не вирус ли? :)
>>
>>
>
>боишься, да!!! :-) запусти и увидишь.
>
Я не боюсь :)). Просто в сообществе ПО принято распространять и исходный
код, чтобы его модифицировать и определить алгоритм работы.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

В Втр, 10.02.2004, в 09:10, Kolotov Alexandr пишет:

> KAS> Blackdown Java-Linux
> KAS> Java(TM) 2 SDK, Standard Edition
> KAS> Version 1.4.1-01
> KAS> (Based on Sun's Version 1.4.1_01-b01)

> как и где?

Я полагаю, в пятницу на Театральной. на RW-шку закатну... Потом вернешь
со свежим lindocs ;)

>KA> Как итог: пункты меню
>KA> - Главная (новости города, ссылки на аналитику)
>KA> - О KirovLUG (общая инфа, персоналии)
>KA> - Документация
>KA> - От KirovLUG
>KA> - Переводы
>KA> - Ссылки
>KA> - Проекты
>KA> - От KirovLUG
>KA> - Ссылки
>Во всяком случае это то с чем можно начинать...
>
>KA> - Гостевуха (по желанию администратора)
>KA> - Форум (по желанию администратора)
>Что касаемо гостевой и форума, мое устоявшнееся мнение такое: надо
>иметь только форум. Причина простая, привычка русских пользователей
>
Думается, при наличии данной рассылки особой нужды в форуме нет.
ИМХО рыссылка удобнее: получил почту, спокойно в оффлайне прочитал,
ответил. А вот чат был бы кстати.

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

KA> если заморачиваться по поводу своего дизайна не хочется, то можно
KA> поступить, как поступают многие - WIKKI.
А что такое WIKKI? Не сталкивался, поясни, пожайлуста...
На самом деле смысл этой фразы был следующим: дизайн - он сам
получится. Требования, конечно, есть: должен быть строгим, не должен
отвлекать, быть, не знаю как и перевести, usability. Но, я бы не стал
обсуждать подробности в духе: "в левом верхнем углу сайта квдрат 30x30
пикселей красног цвета, от него две серых полосы и т.д..." А вот
контент обсудить действительно стоит. По двум причинам: (а) наверняка
найдется несколько новых предложений и (б) они преобретут
удобоприемлимую форму, которая получится более удачной, нежели
предложенная начальная. В конце концов, человек приходит на сайт за
информацией, а отнюдь не оценивать эстетические изыски дизайнера.

KA> Относительно своего сборника документации. Помещать его в не
KA> архивированном виде не вижу смысла, т.к. все его материалы есть в
KA> инете, тем более что публикация материалов может затронуть вопрос об
KA> авторском праве, с чем бы я сталкиваться не хотел. Поэтому рекомендую
KA> давать ссылку для скачивания одного архивного файла. Кировские
KA> пользователи смогли бы переписать доки у меня, а ссылка бы была
KA> необходима для жителей других регионов.

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

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

Кстати, сейчас мысль пришла - а если переводить man`ы и выкладывать их
на сайт. Правда, я вот что-то не знаю технических особенностей, но
ведь и формат и размещение их известны?

Z>> (б) аналитический обзор - весьма неплохое средство, при хорошем уровне
Z>> аналитики, само по себе представляет далеко не меньший интерес, нежели
Z>> пересказ новостей. (в) благодаря этому можно иметь репутацию сайта
Z>> имеющего свое собственное мнение - а это весьма мощный "плюсик"...
KA> меня устраивает. В каком виде это будет? Предлагаю: короткая новость на
KA> главной странице с ссылкой на аналитическую статью, после статьи(путь
KA> даже маленькой) идут комментарии других экспертов (анонимусов -
KA> давить ;)
Так тоже неплохо. Но в оригинале имеось ввиду, что идет такой связный
текст, охватывающий пять-шесть новостей, которые мы считаем важными, с
элементами аналитики. А вот идея насчет нескольких экспертов весьма
интересна, я как-то об этом не подумал... Особенно, если брать во
внимание неизбежную связь со страницей персоналий...

KA> Как итог: пункты меню
KA> - Главная (новости города, ссылки на аналитику)
KA> - О KirovLUG (общая инфа, персоналии)
KA> - Документация
KA> - От KirovLUG
KA> - Переводы
KA> - Ссылки
KA> - Проекты
KA> - От KirovLUG
KA> - Ссылки
Во всяком случае это то с чем можно начинать...

KA> - Гостевуха (по желанию администратора)
KA> - Форум (по желанию администратора)
Что касаемо гостевой и форума, мое устоявшнееся мнение такое: надо
иметь только форум. Причина простая, привычка русских пользователей
таковы, что часть общается только в гостевой, часть - только в форуме,
часть мечется между двумя лагерями, участвуя и в том, и в другом
общении. Таким образом получается, что проблемы, на которые неплохие
решения знают участники гостевой, часами мусолятся в форуме. И,
кстати, наоборот. Форум, imho, является более приемлемой формой
общения...

KA> если заморачиваться по поводу своего дизайна не хочется, то можно
KA> поступить, как поступают многие - WIKKI.
А что такое WIKKI? Не сталкивался, поясни, пожайлуста...
На самом деле смысл этой фразы был следующим: дизайн - он сам
получится. Требования, конечно, есть: должен быть строгим, не должен
отвлекать, быть, не знаю как и перевести, usability. Но, я бы не стал
обсуждать подробности в духе: "в левом верхнем углу сайта квдрат 30x30
пикселей красног цвета, от него две серых полосы и т.д..." А вот
контент обсудить действительно стоит. По двум причинам: (а) наверняка
найдется несколько новых предложений и (б) они преобретут
удобоприемлимую форму, которая получится более удачной, нежели
предложенная начальная. В конце концов, человек приходит на сайт за
информацией, а отнюдь не оценивать эстетические изыски дизайнера.

KA> Относительно своего сборника документации. Помещать его в не
KA> архивированном виде не вижу смысла, т.к. все его материалы есть в
KA> инете, тем более что публикация материалов может затронуть вопрос об
KA> авторском праве, с чем бы я сталкиваться не хотел. Поэтому рекомендую
KA> давать ссылку для скачивания одного архивного файла. Кировские
KA> пользователи смогли бы переписать доки у меня, а ссылка бы была
KA> необходима для жителей других регионов.

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

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

Кстати, сейчас мысль пришла - а если переводить man`ы и выкладывать их
на сайт. Правда, я вот что-то не знаю технических особенностей, но
ведь и формат и размещение их известны?

Z>> (б) аналитический обзор - весьма неплохое средство, при хорошем уровне
Z>> аналитики, само по себе представляет далеко не меньший интерес, нежели
Z>> пересказ новостей. (в) благодаря этому можно иметь репутацию сайта
Z>> имеющего свое собственное мнение - а это весьма мощный "плюсик"...
KA> меня устраивает. В каком виде это будет? Предлагаю: короткая новость на
KA> главной странице с ссылкой на аналитическую статью, после статьи(путь
KA> даже маленькой) идут комментарии других экспертов (анонимусов -
KA> давить ;)
Так тоже неплохо. Но в оригинале имеось ввиду, что идет такой связный
текст, охватывающий пять-шесть новостей, которые мы считаем важными, с
элементами аналитики. А вот идея насчет нескольких экспертов весьма
интересна, я как-то об этом не подумал... Особенно, если брать во
внимание неизбежную связь со страницей персоналий...

KA> Как итог: пункты меню
KA> - Главная (новости города, ссылки на аналитику)
KA> - О KirovLUG (общая инфа, персоналии)
KA> - Документация
KA> - От KirovLUG
KA> - Переводы
KA> - Ссылки
KA> - Проекты
KA> - От KirovLUG
KA> - Ссылки
Во всяком случае это то с чем можно начинать...

KA> - Гостевуха (по желанию администратора)
KA> - Форум (по желанию администратора)
Что касаемо гостевой и форума, мое устоявшнееся мнение такое: надо
иметь только форум. Причина простая, привычка русских пользователей
таковы, что часть общается только в гостевой, часть - только в форуме,
часть мечется между двумя лагерями, участвуя и в том, и в другом
общении. Таким образом получается, что проблемы, на которые неплохие
решения знают участники гостевой, часами мусолятся в форуме. И,
кстати, наоборот. Форум, imho, является более приемлемой формой
общения...

В сообщении от Вторник 10 Февраль 2004 14:37 Kolotov Alexandr написал(a):
>
> дык, тут как раз и возникает дилема. Компьютерщики не разу не бывав (или
> забыв) рядовыми пользователями пишут программы, на которых этот самый
> рядовой пользователь работать не сможет без пинков такого же
> компьютерщика (вспомним, прогу для отчетов в пенс. фонд, а также для
> отчетов в налоговую, программу для обмена платежными документами с
> банком). Т.е. вроде бы ТЗ ясно поставлено: формулы
> раскрыты, формы предоставлены. Дык, блин, какого лешего написано!!!
> Почему пишем под 80x25-интерфейс, ведь весь мир уже давно на нормальном
> GUI? Почему пишем четко под MicroSoft совершенно забывая про
> пользователей других OS (понятно, что их мало, но ведь они есть!!!).
> Ведь быстродействия не нужно (все равно человеческий фактор дает
> бОльшие задержки) - был бы красивый выход - писать на Java (может
> кто-нить еще что предложит). Все в данном случае упирается в
> квалификацию программиста - они просто лучше не смогли сделать.

Все упираеться в человеческую лень.
А то что интерфейс под 80х25 так не надо забывать, что некоторые организации

используют еще 286, 386 железки они то бедные не как не могут под нормальным

GUI работать.
А сидит в этомже пенсионном фонде программист так лет 50-55 и знает только
свой любимый DOS, а остальное ему по барабану. Вот и растягиваеть прогу
которую можно мин так за 5 нарисовать на целый день, видимость работы
создает.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Ostrovskiy.

Вы писали 10 февраля 2004 г., 17:26:05:

OI> Мешаеть отсутсвие грамотно составленного тех задания, кто с этим сталкивался
Вот тут то и нужно написать Howto по постановке задачи,или по
копаться позакромам родины ведь навернека для этого еще в соц
времена был ГОСТ.(раз гост от и должны быть толкования)
OI> поймет. Как звучить задание бухгалтера по настройке бух программы: "Настрой

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

OI> положено, а за ошибки бухгалтера по работе с прогой пинать будут админа,
типа

OI> это он все неправильно сделал, а то что они сами неправильно кнопки нажимают

OI> это ни кого не интересуют.
Что самое интересное это нисколько не зависит от сложности программы.
Сколько не долби их а складывается ощущение что вечерами
они(юзеры)посещают курсы компьютерной НЕ грамотности!

Наверника у некоторых юзеров дома есть комп.для прикола спросите как
они его покупали.Типичный случай в магазине -"Дайте мне пентиум 4".Cамые "умные"
спрашивают-"Какой щас самый крутой компьютер?Пентиум 4 или уже 5"
Ответ-Сега-мега-драйв.
Большинство так-же полоховски подходит к приобретению бытовой и
электронной техники.Бороться с этим либо безполезно,либо
доказывать необходимость оплачивать труд соответствующих
специалистов.
Вообще прихожу к выводу что к работе с юзерами нужно подходить
более формализировано и технологично.Иначе
кухарка(бухгалтер,секретарь,оператор etc) так и останется кухаркой
(кухарем).

OI> Автоматизация предприятия вообще надо проводить с ротой автоматчиков, чтобы

OI> юзеры нажимали на нужные кнопки, а не что попало.
С этим полностью согласен ,хотя не уверен что это правильно.
Как вариант предлогаю внедрять чтото типа техминимума работы с
компюьтером(приложением).

В сообщении от Вторник 10 Февраль 2004 14:48 Kolotov Alexandr написал(a):
> >> Плюс ко всему, это действительно очень поможет продвижению Linix на
> >> оффисные машины в нашей стране.
>
> OI> Это в большей степени зависит от админа, что или кто мешает посадить
> секреторя OI> на линукс?
>
> хм. а действительно что? у кого нить есть уже наработки по этому
> вопросу?
Лично я сам сижу и на работе под RH 9.0 и дома ALTJunior 2.1
Секретаря можно посадить под линукс, если тот в своей работе не использует
специфического софта.

С 1С можно поступить следующе:
Как не печально поднять виндовый сервак с терминалами, на рабочие станции
ставим линукс с пакетом rdesktop и работайте на здоровье в системе сервер
приложений.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

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

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: akmypo***@m*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

>> Плюс ко всему, это действительно очень поможет продвижению Linix на
>> оффисные машины в нашей стране.

OI> Это в большей степени зависит от админа, что или кто мешает посадить секреторя
OI> на линукс?

хм. а действительно что? у кого нить есть уже наработки по этому
вопросу?

А я же скажу что мешает мне:
1. Наработанная база DOC и XLS документов. Все они корректно откроются в
OO и подобных ему (CrossOffice не рассматриваем). Причем довольно часто
среди данных документов попадаются документы со внедрением VB-скриптов -
кто будет переписывать?
2. "Собственное" программное обеспечение внутри офиса - 1С (секретарь по
своим обязанностям должна проводить в нем некоторое время - ничего не
создает но отчеты делает. Она не выполняет бухгалтерские функции -
просто вот такая навороченная конфигурация)
3. "Навязанное" ПО - система обмена платежными документами Банк-Клиент.
Текущая версия под 80x25-интерфейс, нормальная виндовая уже 3 года как
планируют выпустить из тестинга...

Вот пока все, вроде...

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: akmypo***@m*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

OI> Мешаеть отсутсвие грамотно составленного тех задания, кто с этим сталкивался
OI> поймет. Как звучить задание бухгалтера по настройке бух программы: "Настрой
OI> ка мне рознечную реализацию" и все ни проводок ни схемы налогообложения ни
OI> чего, все коротко и ясно. Или сделай именно так как мне надо, а не так как
OI> положено, а за ошибки бухгалтера по работе с прогой пинать будут админа,
типа
OI> это он все неправильно сделал, а то что они сами неправильно кнопки нажимают
OI> это ни кого не интересуют.
OI> Ведь к токарному станку не поставят кого попало, так по чему к компьютеру
OI> допускают людей которые на нем работать не умеют?
<skip>
OI> Автоматизация предприятия вообще надо проводить с ротой автоматчиков, чтобы
OI> юзеры нажимали на нужные кнопки, а не что попало.

дык, тут как раз и возникает дилема. Компьютерщики не разу не бывав (или
забыв) рядовыми пользователями пишут программы, на которых этот самый
рядовой пользователь работать не сможет без пинков такого же
компьютерщика (вспомним, прогу для отчетов в пенс. фонд, а также для
отчетов в налоговую, программу для обмена платежными документами с
банком). Т.е. вроде бы ТЗ ясно поставлено: формулы
раскрыты, формы предоставлены. Дык, блин, какого лешего написано!!!
Почему пишем под 80x25-интерфейс, ведь весь мир уже давно на нормальном
GUI? Почему пишем четко под MicroSoft совершенно забывая про
пользователей других OS (понятно, что их мало, но ведь они есть!!!).
Ведь быстродействия не нужно (все равно человеческий фактор дает
бОльшие задержки) - был бы красивый выход - писать на Java (может
кто-нить еще что предложит). Все в данном случае упирается в
квалификацию программиста - они просто лучше не смогли сделать.

З.Ы. Все это чисто риторическое восклицание...

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: akmypo***@m*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.kirovlug-list@subscribe.ru
Отписаться: mailto:comp.soft.linux.kirovlug--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru