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

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

Не хватает:
Чего-то совместимого с VISIO по формату документа, чтобы можно было рисовать схемы на обоих платформах.
1С
Игр

Для бизнеса, на мой взгляд, в первую очередь не хватает 1С и AutoCAD.

В дополнение к вышеперечисленному не хватает пакета вроде MathCAD.
Ну и чего-нибудь толкового для распознавания текстов.

1с - не хватает очень, нет программ для распознования текста, про автокад - сегодня хотел просмотреть, что за CADы на диске с Mandriva 10.0 Official edition шли

[quote=edge]
Чего-то совместимого с VISIO по формату документа, чтобы можно было рисовать схемы на обоих платформах.
[/quote]

Фильтр-конвертор к OpenOffice для *.vsd файлов и в винде бы не помешал.

Поддержки оборудования действительно не хватает, часто берешь устройство, а там драйвера для всех версий винды и почти всех версий МакОС, а про Linux ни слова. Хотя по количеству компов с этими ОС, Linux уже обошел МакОС, по-моему.
<span class='smallblacktext'>[ Редактирование 06.02.2006 - 11:58:17 ]</span>

программеров нехватает

Мне для перевода юзеров под свободные системы не хватает следующего:
1. Более полной совместимости OpenOffice с MicrosoftOffice
2. Возможности запуска приложений написанных на VBA (Это скорей следствие первого пункта, но таки)
3. OCR (распознавание текстов)
4. AutoCAD
5. Visio
6. Гарант/Консультант+ (всё никак их не попробую в wine запустить. Никто не пробовал?)
7. Сметные программы GrandSmeta/SmetaWizard
8. 1С
9. Драйвера

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

Поддержка win-модемов, а конкретно, ZyXel PCI.

[quote=cin]
6. Гарант/Консультант+ (всё никак их не попробую в wine запустить. Никто не пробовал?)
[/quote]
Пробовал. Глючит так, что не дай бог. Причем под любыми версиями wine

Про Гарант (Консультант) - долго над этим думал, нашел такой выход: и Гарант и Консултант за абон. плату дают доступ к закрытой части своего сайта. Сумма абонплата+плата за трафик -> к стоимости легального комплекта. Хотя понимаю, что это полумера

У Консультанта даже на открытой части сайта материалов более чем достаточно. Но... XML-контент. Непробиваемо.

[quote=igorsia]
неудобно настраивать систему - только yast приблизился к некоему подобию конфигуратора, но у него другая проблема - теперь нельзя простые вещи делать "ручками"[/quote]

согласен с этим, хоть и привык делать "ручками", но...
+ поддержка железа...
+ 1С
+ поддержка MS VBA в Open Office, для запуска готовых программ и макросов, написанных под MSExcel & Word

ну это вроде самое главное...

Хочу нормальную проверку правописания русского

Не хватает хороших графических редакторов. GIMP вещь неплохая, но все-таки до Фотошопа ему далеко (особенно касается pre-press). С редакторами векторной графики вообще полная засада.

В линукс очень не хватает унифицированного сервиса для конфигурирования системы.
Куча файлов /etc по posix это всё же архаика.
Нужна система чем-то похожая на windows registry, причём более функциональная.
<span class='smallblacktext'>[ Редактирование 20.03.2006 - 13:45:41 ]</span>

Плавали, знаем. windows registry не есть хорошо. Разрушение "файла регистра" разрушает всю ситему. Для настроек есть /etc. Отклонение от этой нормы есть нарушение LSB и posix. Ценносто текстовыъх файлов в том, что они как правило понятны и требуют минимальных телодвижений для редактирования. Немаловажно при удалённой работе.

[quote=urimo]Хочу нормальную проверку правописания русского[/quote]
*spell уже не считается нормальной?

>>Для подавляющего числа бизнес применений-естественно 1С.

[url=http://1l.w4b.ru/]Вот вам 1L[/url].

[b]Vitls[/b]
Я не говорю заменять! Я предлагаю сделать единный ООП ориентированный интерфейс к файлам в /etc, можно будет таким образом ещё повысить безопасность и унифицировать настройки. Лучше если настроечные файлы это будут носить xml вид - можно и руками править и xml-rpc всяких полно, на ручной правке можно автоматом валидаторы пропускать и для отчётов можно xslt приатачить.

xml в топку. Больше ресурсов потратится на его обработку. Централизованная системы настройки (с сохранением в рамках текущей модели LSB и posix) штука интересная. В первом приближении можно рассмотреть webadmin или YAST. Но как показывает практика такие решения слишком умны и громоздки.

[quote=Vitls]Централизованная системы настройки (с сохранением в рамках текущей модели LSB и posix) штука интересная. В первом приближении можно рассмотреть webadmin или YAST. Но как показывает практика такие решения слишком умны и громоздки.[/quote]
Опять двадцать пять! webmin, webadmin или YAST меня неинтересуют!
Чего не хватает я уже сказал - унифицированной системы управления/программирования настройками OS и приложений, на подобии registryAPI! Я не утверждаю что registryAPI хороша во всём, но и не надо отрицать что такой унифицированный подход к настройке системы более оптимален. Возможно не xml использовать, а например ldap (в Mirosoft в будущих реализациях Windows собираются как раз в этом направлении двигатья - интеграция ADAM (AD для приложений - по сути LDAP), это уже впринципе есть - R2 ), но всё же я думаю использование xml было более строгим и в тоже время достаточно гибким решением для унификации системы конфигурирования.

[quote=Vitls]xml в топку. Больше ресурсов потратится на его обработку.[/quote]
Хм... А как обстоят дела сейчас? Для того что бы считать конфигурацию, используется чтение, затем парсинг (не всегда оптимальный), затем в приложении свой парсинг (зачастую не оптимальный), и причём каждый волен сам придумывать всякую лабуду, типа пихёнт в файл конфу, картинки и бд и сидит рисует к нему фейс.
А если сделать оптимизированный движек, да интегрировать его модуль в ядро, получится совсем не тормозное и не ресурсоёмкое решение, а наоборот единная система конфигурирования с хорошим быстродействием, и никто не просит вас загружать всЕ конфигурации в озу (прочитал попарсил выкинул, остался файл только в файловом кеше, который либо освободится позже, либо поможет быстрее прочитать файл если он снова потребовался).

>> ...да интегрировать его модуль в ядро...
А в ядро его нафига?

[quote=RNZ]
Хм... А как обстоят дела сейчас? Для того что бы считать конфигурацию, используется чтение, затем парсинг (не всегда оптимальный), затем в приложении свой парсинг (зачастую не оптимальный), и причём каждый волен сам придумывать всякую лабуду, типа пихёнт в файл конфу, картинки и бд и сидит рисует к нему фейс.
А если сделать оптимизированный движек, да интегрировать его модуль в ядро, получится совсем не тормозное и не ресурсоёмкое решение, а наоборот единная система конфигурирования с хорошим быстродействием, и никто не просит вас загружать всЕ конфигурации в озу (прочитал попарсил выкинул, остался файл только в файловом кеше, который либо освободится позже, либо поможет быстрее прочитать файл если он снова потребовался).[/quote]

Пожалуйста, приведите цифры: сколько времени система проводит в парсинге конфигов? Вы правда думаете, что выигрыш будет заметен на глаз? А в ядро -- это да... LDAP + XML DOM в ядро, GTK и QT тоже. И вообще, нахрена нам userspace? На context switching столько времени уходит... Долой все rings выше ring0! Настоящие пацаны в userspace не выходят.

[b]Nick, mitix[/b]
Ну в ядро интегрировать XML DOM не обязательно, но в целом, интеграция может позволить читать конфу для ядра прямо из xml, и полностю уйти от обычных текстовых конфигов.
Конфиги же, имеют иной раз столь разную структуру, что на изучение некоторых уходит времени ну очень дофига (особенно когда они пустые и непонятно для какой программы этот конфиг предназначен).
Допустим, развивая тему, вот есть конфиг asound.conf
<div class='indent'># Generated by system-config-soundcard, do not edit by hand
defaults.pcm.card 0
defaults.pcm.card 0</div>
Параметры повторяются. А почему? Просто, потому что конфигурационный скрипт не ищет параметр раннее существоваший и втыкает по второму разу и так будет каждый раз при запуске скрипта конфигурации, а если бы был валидатор, который отсекал бы для конфигов такие грехи автоматом, то появление повторяющихся переменных можно было бы исключить изначально.

Другой пример:
<div class='indent'>core.network.auto_ip 0
core.network.public_ip 192.168.100.100</div>
Для переменной auto_ip присутствует возможность задать не булевое значение. Возможная ошибка - очевидна, а зато для решения её программа/скрипт обрабатывающая конфиг обязательно должна иметь проверку значения переменной на соотвествее типу.
Конфиг, подобный ниже указанному позволил бы сразу однозначно определять тип переменной в конфигурации. Плюс - очевиден.
<div class='indent'>
<pref name='core'>
<pref name='network'>
<pref name='auto_ip' type='bool' value='0' />
<pref name='public_ip' type='string' value='192.168.100.100' />
...</div>

Ещё немножко:
Можно генерить доку/хинты прямо по конфигурации, и очень оптимально
<div class='indent'>
<pref name='core'>
<pref name='network'>
<pref name='auto_ip' type='bool' value='0'>
<local_schema locale="en" short_desc="Automatic IP configuration">
<longdesc>Bla-bla-bla...</longdesc>
</local_schema>
<local_schema locale="ru" short_desc="á×ÔÏÍÁÔÉÞÅÓËÏÅ ÐÏÌÕÞÅÎÉÅ IP-ÁÄÒÅÓÁ">
<longdesc>âÌÁ-ÂÌÁ-ÂÌÁ...</longdesc>
</local_schema>
</pref>
<pref name='public_ip' type='string' value='192.168.100.100' />
...</div>

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

Насчёт скорости парсинга - я считаю что не все перловые скрипты всегда оптимально в не|юзерспейсе парсят конфиги, а на каждой не доделанной мелочи мы терям лишнюю десятку тактов.
Кроме того можно например строить по xml-файлам индексы, да и в самом xml-файле в начале можно стоить индекс для "тела" xml-конфигурации, тем самым ускоря работу с конфигурационными файлами в разы, по сравнению с обычной обработкой текстовых конфигов.
<span class='smallblacktext'>[ Редактирование 22.03.2006 - 03:23:40 ]</span>

2[b]RNZ[/b] Зачем же столько лишних букв?

Проблема ручной правки текстовых конфигов надуманна.
А вы еще пытаетесь ее усложнить XML.
Не пользуйтесь графическими конфигурилками и тогда проблема
проверки повторяющихся параметров отпадет сама собой.

>Чего не хватает я уже сказал - унифицированной системы управления/программирования настройками OS и приложений, на подобии registryAPI!
А с приложениями чего делать изволите? Переписывать, чтобы они умели с этим патологический regAPI работать? Может тогда проще новую ОС разработать? Куда денем posix?

2 Ne01eX. Согласен. По принципу Оккама, не плодите сущностей без надобности.

[b]Ne01eX[/b]
Да причём тут "графические конфигурилки" и надуманость?! Факт в том что для решения какой нибудь трифиальной проблемки иной раз приходится "на голову встать", что бы найти параметры которые будут оптимально соотвествовать определённым условиям.
Например - сколько файлов нужно отредактировать вручную, что бы настроить клиентское pptp соединение на плохом линке, и сколько параметров, нужно знать? Читать man по pptpd, и править по нему как писано? И сколько таких man'ов читать? Или может googlить?

[b]Vitls[/b]
Давайте не будем о паталогиях, это уже флей. Я не предлагаю с корнем всё рубить, я предлагаю расширить возможности, а уж путь программист сам выбирает, что пользовать ему - унифицированный подход на базе xml аля regAPI или пользовать бескрайние возможности текстовых файлов (как того требует posix).

RNZ:

Несколько тактов -- это да... Это стоит того... Будет ваш Linux грузиться не 30 секунд, а 28 и процессор будет простаивать не 99% времени, а 99.1%. Это, конечно, повод, чтобы переписать все программы и переучить всех админов...

>>>Например - сколько файлов нужно отредактировать вручную, что бы настроить клиентское pptp соединение на плохом линке, и сколько параметров, нужно знать? Читать man по pptpd, и править по нему как писано? И сколько таких man'ов читать? Или может googlить?

http://www.chelcom.ru/support-vpn-linux-pptp.html <- Линк в помощь.
А плохая связь это уже не ваша проблема, а проблема связистов.

Вот тут: [link=http://citforum.ru/operating_systems/linux/distro-select/]citforum.ru/operating_systems/linux/distro-select/[/link] можно посмотреть сравнение различных дистрибутивов Linux + FreeBSD. Это, конечно, просто еще одно мнение, но можно составить из списка недостатков хороший список того, что следует доработать либо унифицировать.
<span class='smallblacktext'>[ Редактирование 23.03.2006 - 13:14:24 ]</span>

[b]Nick[/b]
Не утрируйте, что бы ты сказал когда тебе понадобилось бы RT исполнение?
Короме того не смотрите так узко на это.

[b]Ne01eX[/b]
Уважаемый, спасибо за ссылку, но не надо объяснять мне как настраивать pptp в тривиальном случае. А вот проблемы, провайдера иной раз не касаются, основное кол-во клиентов работает на windows, и главный аргумент провайдера - в windows всё работает (реально работает), а что бы на linux работало надо "на голову вставать" - tcpdump запускать, mru, mtu менять, работу mppe проверять с mschap2 париться, и вообще с комбинациями парамеров шаманить так, что иной раз в пору бубен заказывать.

[quote=RNZ][b]Vitls[/b]
Я не говорю заменять! Я предлагаю сделать единный ООП ориентированный интерфейс к файлам в /etc, можно будет таким образом ещё повысить безопасность и унифицировать настройки. Лучше если настроечные файлы это будут носить xml вид - можно и руками править и xml-rpc всяких полно, на ручной правке можно автоматом валидаторы пропускать и для отчётов можно xslt приатачить.[/quote]

Нуну... собери в кучу разнородные и разнотипные конфиги.. Попробуй гуй к апитаблам прикрутить. Да еще чтобы bash конфиги понимало... Весь шарик спасибо скажет...

[b]Sheridan[/b]
я, уже сказал, предлагаю не менять всё, можно так:
/etc - храним старые конфиги
/etc-xml - пишем новые пользуя xml аля RegAPI

IMHO овчинка все же выделки не стоит

[quote=RNZ][b]Nick[/b]
Не утрируйте, что бы ты сказал когда тебе понадобилось бы RT исполнение?
Короме того не смотрите так узко на это.

[b]Ne01eX[/b]
Уважаемый, спасибо за ссылку, но не надо объяснять мне как настраивать pptp в тривиальном случае. А вот проблемы, провайдера иной раз не касаются, основное кол-во клиентов работает на windows, и главный аргумент провайдера - в windows всё работает (реально работает), а что бы на linux работало надо "на голову вставать" - tcpdump запускать, mru, mtu менять, работу mppe проверять с mschap2 париться, и вообще с комбинациями парамеров шаманить так, что иной раз в пору бубен заказывать.

[/quote]

Для RT есть другие OS. Не передергивайте. Кстати, в RT латентность меньше, но и производительность тоже (сюрприз?). "Не смотрите узко" на что? На вашу идею сделать Windows из Unix? Причем, сделать плохую Windows, неудачную, хуже настоящей?

А насчет настройки PPTP -- так это вам неудачные дистрибутивы попадались. Неудачные для _пользователя_, потому, что админ и так настроит, без жалоб на тяжелую половую жизнь с Linux. Я вот не жалуюсь, я немало настроил linux PPTP-клиентов и серверов, "у меня все работает" (C). А вы или возьмите любой современный дистрибутив с графической конфигурялкой, или напишите свою мега-супер-bloatware (болтать все могут, а как до дела доходит, сразу в кусты? предложили -- напишите!), или ступайте себе в Windows, где о вас уже позаботились.

>>Уважаемый, спасибо за ссылку, но не надо объяснять мне как настраивать pptp в тривиальном случае. А вот проблемы, провайдера иной раз не касаются, основное кол-во клиентов работает на windows, и главный аргумент провайдера - в windows всё работает (реально работает), а что бы на linux работало надо "на голову вставать" - tcpdump запускать, mru, mtu менять, работу mppe проверять с mschap2 париться, и вообще с комбинациями парамеров шаманить так, что иной раз в пору бубен заказывать.

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

2. И если вам не удалось настроить соединение в приведенном выше классическом случае, значит в пору обратиться в техническую поддержку, которые обязаны настроить вам соединение в той ОС, в которой вы пожелаете. Отмазка "в маздае все пашет, идите все нах.." уже не катит. Я лично общался с человеком, который выиграл суд у провайдера на подобную тему.
3. Если проблема соединения не в настройках, а именно в плохой связи, что вы упорно подчеркиваете, то впору звонить телефонистам. Вы им за это деньги платите в виде абоненской платы, а потому они должны вас обеспечить качественной связью.

Поверьте, осущестить выше перечисленное не только значительно проще, чем перевернуть весь мир на уши XMLом весь мир, но и эффективней, в первую очередь, для вас. Однако, вы уже не в первом посте блистали глубокими познаниями в XML и не в первом посте аргументированно доказывали его эффективность. Что-ж дерзайте. Переведите хоть что-нибудь из ПО используещее каталог /etc с plain text на XML и если это зачинание будет позитивным (иметь видимое приемущество перед plain text), то я уверен, что Linux-сообщество вам поможет. Более того, я вам обещаю как координатор RTK Linux сопровождение вашего форка в составе дистрибутива.

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

[quote=RNZ][b]Sheridan[/b]
я, уже сказал, предлагаю не менять всё, можно так:
/etc - храним старые конфиги
/etc-xml - пишем новые пользуя xml аля RegAPI
[/quote]
1. А нафига нам нужен overhead xml'ный?
2. Править вручную - неудобно
3. Формат не предназначен для визуального просмотра

xml имеет смысл применять когда действительно нужен многомерный конфиг. Например описание интерфейса окна. А для остального набного более удобен обычный 2мерный ini формат или одномерный key=value

Короче. Не пытайся везде прикручивать сложности. Там где можно без сложностей, пускай будет просто. xml это тяжелый формат, и не надо его прикручивать там где без него можно обойтись. А в ядре оно и подавно не нужно :)))
Не умножай сущности.
[ Редактирование 24.03.2006 - 08:24:34 ]

а зачем держать две системы конфигов? не проще ли отображать конфиг из xml в псевдофайловую систему etcfs сделанную на подобе sysfs и procfs

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

[quote=igorsia]а зачем держать две системы конфигов? не проще ли отображать конфиг из xml в псевдофайловую систему etcfs сделанную на подобе sysfs и procfs
[/quote]

Ага, и эта файловая истема будет генерить конфиги при помощи XSLT. Какой хороший получится тормоз! Windows до такого не дошла...

Еще бы не помешал аналог ActiveDirectory, хотя в RHEL уже что-то подобное имеется.

2 exo: LDAP уже не в моде?

Остальным. Предлагаю тему etcfs и подобных реестров вынести в отдельную нитку.

[quote=Nick][quote=igorsia]а зачем держать две системы конфигов? не проще ли отображать конфиг из xml в псевдофайловую систему etcfs сделанную на подобе sysfs и procfs
[/quote]

Ага, и эта файловая истема будет генерить конфиги при помощи XSLT. Какой хороший получится тормоз! Windows до такого не дошла...
[/quote]
Благородный дон ежедневно с утра до вечера меняет конфиги?

[quote=Vitls]2 exo: LDAP уже не в моде?

Остальным. Предлагаю тему etcfs и подобных реестров вынести в отдельную нитку.[/quote]
Надо не предлагать а выносить...

[quote=igorsia]
Благородный дон ежедневно с утра до вечера меняет конфиги?
[/quote]
Благородный дон не включает компутер? Иначе ничем нельзя объяснить тот факт что у него конфиги ничто не читает...

[quote=igorsia][quote=Nick][quote=igorsia]а зачем держать две системы конфигов? не проще ли отображать конфиг из xml в псевдофайловую систему etcfs сделанную на подобе sysfs и procfs
[/quote]

Ага, и эта файловая истема будет генерить конфиги при помощи XSLT. Какой хороший получится тормоз! Windows до такого не дошла...
[/quote]
Благородный дон ежедневно с утра до вечера меняет конфиги?
[/quote]

Ваша etcfs будет генерить конфиги один раз и кешировать? Тогда ОК. Правда, производительности запуска это все равно не прибавит. Но вопрос не в этом. БОльшая часть конфигов читается при запуске, то есть при загрузке компьютера (у меня -- примерно раз в месяц). Все остальное время они могут храниться где угодно и как угодно -- не влияет.

на тему /etc or /etc-xml создал ветку, в программазме -> http://www.nclug.ru/forum_viewtopic.php?8.7718