Обсуждение статьи "Развитие Linux: куда теперь?" (http://www.osrc.info/print.php?article.113)

[cubique]

linux для меня всегда был привлекателен тем, что предоставляет
свободу выбора... свободу выбора во всём и вся! я сам решаю нужен ли мне в linux текстовый
процессор или latex, kde или gnome, консоль или Х...как хочу, так и верчу... и мне было бы очень
жаль, если бы эту свободу выбора у меня отобрали... если бы всякие авторы подбных статей
решали бы за меня что мне нужно... я тогда уж на Mac пересяду, там тоже уже всё решено за меня.
но зато гораздо более грамотней...

[ddc]

если бы всякие авторы подбных статей

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

[alv]

Ребята, давайте без перехода на личности
а то всэх зарэжу

[ddc]

Ребята, давайте без перехода на личности

Ну я же не сказал про него ничего плохого...

[t.t]

Да никто у Вас ничего не отнимает!

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

[alv]

Да никто у Вас ничего не отнимает!

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

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

[ddc]

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

Стандарты и так есть (благодаря этому у меня есть rpm), но пока они не интересны. Однако статья писалась в виду шедших тогда валом новостей о стандартизации GUI от вендоров и наростающего писка о необходимости иметь одну платформу.

[Bruce]

и тут прихожу я и говорю такую мысль:

А кто из вас занимался разработкой софта под линукс? Я сам - нет. Но вполне представляю, что велосипед в коммюнити изобретается каждый раз. Вылезет полезная программка - понянет за собой свои библиотеке. Посчитайте, сколько у вас в дистрибутиве _разных_ библиотек, занимающихся одним и тем же? И есть ли это хорошо? Да и установка софта под линуксом весьма нетривиальна (если не из дистриба) - помню, как смеялся до слёз, когда увидел впечатления чела от установки lincity-ng - да, я тоже его ставил. поставил. часа 3 ставил. пока всё ему нашёл, скомпилил, его самого собрал, потом получил 1-2 фпс и успокоился . Извините, но в винде гамесу как-то проще поставить, все велосипеды всегда таскаются с собой (окрома directx), и то, что всё собирать вручную - круче - мне не нравится. Ладно бы не претендовали бы мы линукс на десктоп, так нет же - обязательно нужно сравнивать. Сидел бы я, например, под netbsd - я бы не выпендривался, что непросто поставить . И это только инсталл - в ужас впадаю от процесса разработки софта. Никто не задумывался, почему тот же adobereader сделан на motif? чтобы поддерживался везде, где есть графика. И это хорошо - никаких зависимостей, проблем с инсталляцией - минимум. линуксовая nvidia ставится ещё проще, чем виндовая, если знаешь куда копать.

Тут вспоминается интересная история. Как-то раз собрал я ядро в пакеты image и headers - и захотел именно этими хидерами пользоваться при сборке дровов. Да, мне никто не сказал, что с определённой версии ядра (или make-kpkg - не знаю), каталог scripts из хидеров выкинули. Да - я разобрался - откопал пару файликов, скомпилил modpost, всё сожралось и поставилось минут за 15 - НО: обыкновенный юзер (т.е. тот, кто не постоянно что-то ставит и настраивает, а работает в своих личных целях) вряд ли сможет с этим разобраться, потому что в этом случае поведение системы отличалось от ожидаемого. И это в таком качественном дистрибе как дебиан.

И тут хочется сказать ddc, что как раз ms office прекрасно с виндовыми программами взаимодействует (именно его вы писали, как пример эдакого "всё в себе"). Примеры приводить даже стыдно, посмотрите на скриншоты дельфи.

Ещё вспоминается вещь одна. Есть такой d4x. Так вот. Чел, который это писал, назвал себя gtk+ хакером. Вопрос. Нормально ли, чтобы для того, чтобы написать регето-подобную программу, нужно досканально изучить все особенности работы gtk и может ли это пригодиться в других областях? Даже я уже начал понимать, что такие продукты как delphi позволяют писать программы, реально делающие полезные вещи, не зная почти ничего, кроме языка программирования и английского. Вся идея дискуссии в том, что это есть плохо. Чтобы понять как работать с сокетами, нужно, по вашему (ddc), перелопатить все доки, какие есть и уметь писать сокеты хоть на асме. Чтобы сделать гуй, нужно опять заниматься тем же самым (при том никого не волнует, что на смену одного гуя придёт другой - и опять всё начинается сначала). Так вопрос: почему не морочиться и получать работающую вещь сейчас хуже, чем знать досканально, но несвоевременно получать рабочий продукт? Уже сравнивали VC++ и дельфу, и пришли к выводу, что даже крутой профи вряд ли сможет за сравнимое время создать аналогичную по надёжности и возможностям программу на vc++ по сравнению с дельфи. А тут у нас вообще линукс. Kylix не нужен принципиально (это я кстати поддерживаю), но мне почему-то кажется, что всё как-то специально делается сложнее, чем должно быть (именно в программировании). Куча левых библиотек, постоянная ругань на kde с унифицированным насколько можно api. При том, не у всех kde есть. В общем, проблема не столько в юзабельности линукса, а в его целостности и неизбыточности. То же самое и у фри и у любой свободной системы. Я уважаю свободу - свою и чужую - но менять нужно не гуй и юзабельность, а саму архитектуру.

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

[ddc]

И тут хочется сказать ddc, что как раз ms office прекрасно с виндовыми программами взаимодействует (именно его вы писали, как пример эдакого "всё в себе").

Поясните мысль. Что имеется в виду? Вы можете встроить Word в свою программу?

И почему гуй намертво вкомпиливать в ядро? А если сделать по выбору?

В соответствующей теме Вам уже рассказали. Могу повторить и здесь: такой проект (Linux с интегрированным GUI) уже сравнительно давно есть, но его никто не использует, ибо это кроме проблем ничего не доставляет.

А я тут вот её поюзал - да, неудобная по интерфейсу, страшная, но зато работает быстрее линукса (в частности, запуск приложений - firefox раз в 5 минимум быстрее запускается) и с установкой софта проблем нет в принципе.

Тут все вопросы к настройкам и (барабанная дробь!) Firefox'у. Когда я пытался пользоваться OpenOffice, на одном и том же ноутбуке Sony VAIO PCG-GRX570 OpenOffice.org 1.1 для Linux открывался ощутимо быстрей, чем та же версия для Windows. Тако же и с остальным кроссплатформенным и аналогичным ПО.

[Mitja_R]

Поясните мысль. Что имеется в виду? Вы можете встроить Word в свою программу?

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

[ddc]

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

Но только тех компонентов, которые предоставил разработчик, которые он описал.
Кстати, использование COM возможно в любой программе для Windows?

[Mitja_R]

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

Но только тех компонентов, которые предоставил разработчик, которые он описал.

Ну это вообще почти всегда так. Если разработчик не предоставил и не описал свои компоненты, то их использование затруднительно, не так ли?

Кстати, использование COM возможно в любой программе для Windows?

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

[Bruce]

по поводу скорости запуска:
я так же сравнивал юзабельность в целом - у меня в винде практически "инстант-клик", всё на самом деле быстро. Зато в винде хуже распараллеливание процессов . Но раз уж речь зашла о настройках - то и где же про это почитать можно? Почему по ВСЕМ вопросам нужно гуглить? почему не напишут какой-нибудь perfomance howto?

по поводу гуя в ядре: сделали бы нормально - пользовались. логично?

по поводу com: всё равно непонятно, как можно до такой степени не знать ничего о винде. Там есть ещё много интересных фич, которые _работают_ и не так уж и сложно заюзываются. в конце концов, directx и вся 98 винда сделаны на com, а вы (ddc) тут утверждаете... что этим нельзя пользоваться .

[t.t]

даже крутой профи вряд ли сможет за сравнимое время создать аналогичную по надёжности и возможностям программу на vc++ по сравнению с дельфи

Не произносите при мне слова "дельфи" и "надёжность" в одном предложении -- больная тема.

Есть такая технология в Windows, СОМ называется.

Вторая больная тема, кстати говоря.

по поводу гуя в ядре: сделали бы нормально - пользовались. логично?

Не совсем. Чтобы пользовались, надо сделать не просто нормально, а _лучше_ того, что уже есть. Причём _объективно_ лучше, а не с точки зрения того, кто это придумал. Видимо, лучше пока ничего не придумали

А кстати, назвать вам _одну_ причину не включать гуй в ядро, об которую разбиваются все противоположные доводы? Сейчас при зависании иксов что мы делаем? Правильно, срубаем иксы и решаем эту проблему из консоли. А так что мы будем делать? Ядро перекомпиливать? А откуда, если без ядра даже однопользовательский режим не загрузится? С ЖивСиДи? Ну конечно.

P.S. Это так.. попытка приостановить бессмысленный флейм.

[printf]

Есть такая технология в Windows, СОМ называется.

только не это.

[vadiml]

а мне статья понравилась, и я с ней солидарен процентов на 90%. И он, кстати, правильно описал причину моего перехода с Gnome на KDE - мне нравится, что все состоит из маленьких кирпичиков, что каждый из них развивается и везде они ведут себя одинаково, что функциональность программ не режется, а наоборот, улучшается, что система становится для меня более удобной, т.е. ведет себя так, как я ожидаю, а не трачу время на выискивание способа как мне сделать какую нибуть тривиальную операцию - я предпочитаю сам решать что мне в программе надо, а что нет

что интересно - основные оспользуемые программы - не из KDE, но они не следуют по гномовскому пути (мозилла (не firefox!), sylpheed, StarDict, mc, tvtime, vi, xmms, wget)

вся 98 винда сделаны на com

вы несколько заблуждаетесь, это к ней после прилепляли, а чтобы узнать из чего она сделана - посмотрите Эндрю Шульмана и Метта Петрека (у них по win3x была общая книга, а по win9x каждый написал свою - уровень ядра и уровень win api)

[polachok]

а сами они звонят лишь друг другу
обсуждая лишь как прекрасен наш круг
(с)
vadiml, это для Вас и ddc

[ddc]

Почему по ВСЕМ вопросам нужно гуглить? почему не напишут какой-нибудь perfomance howto?

Вот и пишите. Завтра здесь ждём-с.

по поводу гуя в ядре: сделали бы нормально - пользовались. логично?

Нет. Потому что нормальное по-моему очень отличается от нормального по мнению уважаемого Евгения.

а вы (ddc) тут утверждаете... что этим нельзя пользоваться .

Аккуратней, пожалуйста!

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

Ну-ну...

Ну это вообще почти всегда так. Если разработчик не предоставил и не описал свои компоненты, то их использование затруднительно, не так ли?

Lynx легко интегрируется с любой консольной писалкой, смотелкой и т.д. То же с mutt и рядом других программ. Это возможности IPC, с которыми в Windows не сладко... Возможности для прозрачной интеграции в готовое графическое окружение есть у Dillo, и это широко используется в соответствующих системах.

[Mitja_R]

Lynx легко интегрируется с любой консольной писалкой, смотелкой и т.д. То же с mutt и рядом других программ. Это возможности IPC, с которыми в Windows не сладко... Возможности для прозрачной интеграции в готовое графическое окружение есть у Dillo, и это широко используется в соответствующих системах.

Это потому, что указанные программы как раз следуют определенным стандартам и принятым правилам. В никсах свои правила, в винде другие.
P.S. Но, имхо, это уже глубокий оффтоп

[ddc]

Это потому, что указанные программы как раз следуют определенным стандартам и принятым правилам. В никсах свои правила, в винде другие.
P.S. Но, имхо, это уже глубокий оффтоп

Вовсе нет! Одной из отправных точек было различие между взаимодействием "острых" утилит и программными пакетами. Так вот COM - эти технология создания интегрированных пакетов, а IPC в UNIX'ах - технологии интеграции независимых программ. И COM (с ныне многочисленными аналогами из Linux) - это не тот способ, который предполагался к использованию в "чистых" UNIX'ах...

[Mitja_R]

Вовсе нет! Одной из отправных точек было различие между взаимодействием "острых" утилит и программными пакетами. Так вот COM - эти технология создания интегрированных пакетов, а IPC в UNIX'ах - технологии интеграции независимых программ. И COM (с ныне многочисленными аналогами из Linux) - это не тот способ, который предполагался к использованию в "чистых" UNIX'ах...

ИМХО, СОМ - это не технология создания интегрированных пакетов, а, скорее, способ организации межпрограммного взаимодействия. Если следовать предложенной парадигме, то разработчик должен реализовать логику в некотором количестве СОМ-объектов, после чего сделать к ним ГУИ, который будет рисовать кнопочки и вызывать методы объекта, реализующего логику. При этом методы объекта, реализующего логику, могут быть вызваны любым другим приложением. Например, Internet Explorer и MyIE - просто разные "морды" к одному и тому же движку. Множество текстовых редакторов используют один и тот же компонент RichTextEditor. Я сам писал программку когда-то, в ней для проверки орфографии использовался Word, а для формирования и печати отчетов - Excel. Так что с помощью СОМ можно интегрировать независимые программы достаточно успешно. Причем эти программы могут находиться даже на разных машинах в сети, поддерживается аутентификация и многое другое. Разница, имхо, в том, что здесь нельзя все это реализовать из командной строки, как в случае с перенаправлением потоков.
А то, что в "чистых" никсах не предполагался СОМ - так 30 лет назад это и не могло быть реализовано (как я себе представляю) на имеющихся мощностях. Сделали, как смогли - получилось очень удачно. По мне так СОМ - большой шаг вперед в плане межпрограммного взаимодействия и разукрупнения больших программ.
P.S. А то, что СОМ плохо работает, как утверждают некоторые коллеги, так это вопрос радиуса кривизны верхних конечностей и времени, потраченного на изучение вопроса (имхо, разумеется).

[Bruce]

не, вообще я понял, что ddc имеет в виду. но по большому счёту, возможности такие в виндах есть всё равно, просто ими никто не пользуется. а я в свою очередь, под линуксом не пользуюсь ни mutt, ни lynx (только если очень надо файлы другой кодировки в терминале посмотреть), ни емаксом. Вот из той же ОПЕРЫ (которая куда более популярна) что можно использовать в других программах? Или только к ней можно яву прикрутить? Ну и т.д. Стандартны по своей остроте только достаточно простые программы, есть же навалом (это я о дебиане) софта, который писали не следуя вышеописанным стандартам. И которым всё равно пользуются.

[t.t]

P.S. А то, что СОМ плохо работает, как утверждают некоторые коллеги, так это вопрос радиуса кривизны верхних конечностей и времени, потраченного на изучение вопроса (имхо, разумеется).

Раз уж вы эту тему всё таки затронули... Увы, нет. Как выяснилось (экспериментальным путём, к сожалению -- из описаний, естественно, таких выводов сделать было нельзя), COM+ плохо масштабируется; т.е. когда объём приложений (особенно взаимодействующих по сети) и, соответственно, количество одновременно используемых COM-объектов превышают некую критическую массу, вся конструкция становится слишком тяжёлой как в плане машинных ресурсов, так и в плане контроля и управления.

[ddc]

а я в свою очередь, под линуксом не пользуюсь ни mutt, ни lynx (только если очень надо файлы другой кодировки в терминале посмотреть), ни емаксом.

Это и огорчает...

[StraNNicK]

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

[ddc]

Mitja_R
Для меня здесь принципиальный вопрос такой: используя технологии, предлагаемые Microsoft, я должен выбирать компоненты на уровне дизайна программы. Т.е. я должен либо выбрать один компонент RichTextEditor (а их предлагают разные программные пакеты), либо предусмотреть заранее несколько вариантов и сделать в настройках меню для выбора (реально никогда такого не видел). Под UNIX'ами нормальной практикой является выбор пользователем любой программы, т.е. программист выбрал способ по умолчанию, а пользователь поменял на то, что удобней.

Назовите три причины по которым lynx лучше Оперы.

Если мне удобней, мне другие причины не нужны.

[StraNNicK]

А зачем навязывать другим?

а я в свою очередь, под линуксом не пользуюсь ни mutt, ни lynx (только если очень надо файлы другой кодировки в терминале посмотреть), ни емаксом.

Это и огорчает...

Может стОит описать преимущества использования так, чтобы люди сами захотели попробовать?

[Jan2ary]

Java - плохой язык для UNIX'ов.

Простите, что поднимаю, просто интересно. Почему?

[elide]

ребят, вот только не надо про COM, ок?
вот у меня появилась задача: автоматически по номеру патента вытаскивать из базы uspto.gov сам патент в виде кучи tiff картинок.
делается это так: делается запрос к поисковому движку, его ответ распарисвается и получается ссылка на его текстовый вариант. текстовый вариант распарсивается (попутно сохраняясь в файле, имя которого совпадает с названием патента) и получается ссылку на страницу иллюстраций. страница иллюстраций распарсивается, и получается число иллюстраций и ссылка на первую. потом рекурсивно вытягиваются все иллюстрации.
используя bash, wget, sed, grep и gawk я решил эту задачу за 13 минут, 44 секунды (специально измерял).
внимание вопрос: за сколько времени пользователь виндовс решит подобную задачу, используя все богатство компонентов COM, которое предоставляется ему системой?
есть подозрение, что никогда он этого не сделает. ведь для этого нужно знать хотя бы этот конченый VisualBasic, хотя бы знать как работать с COM, и перечитать половину MSDN. при том, что у меня цикл добавление_новой_функции => тестирование => отладка занимает меньше 20 секунд (мне надо лишь скохранить измененный файл и в другом терминале запустить его), я могу обойтись любым текстовым редактором, а потом буду уверен, что этот скрипт будет работать практически под любой Unix-like системой (по крайне мере, перенос на фряху и солярис он перенес без единого изменения).
COM - это супер-пупер технология. у нее есть только один минус - ее совершенно невозможно использовать простому пользователю.
да и программистам хреново... взаимодействие через stdin/stdout, и через COM - это совершенно разные вещи. кстати, многие из вас писали под COM?

[ddc]

Может стОит описать преимущества использования так, чтобы люди сами захотели попробовать?

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

Java - плохой язык для UNIX'ов.

Простите, что поднимаю, просто интересно. Почему?

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

ведь для этого нужно знать хотя бы этот конченый VisualBasic, хотя бы знать как работать с COM, и перечитать половину MSDN.

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

кстати, многие из вас писали под COM?

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