Re: [FS] Перспективы сво бодного ПО в публично м секторе
Woland T wrote: Здравствуйте Maxim Otstavnov Debian Russian! В письме от Peter Novodvorsky [EMAIL PROTECTED] (Wed, 04 Dec 2002 00:41:34 +0300) было написано : Woland T [EMAIL PROTECTED] writes: Да и то, что там было тоже отредактированная версия английского варианта: http://www.dwheeler.com/oss_fs_why.html Откровенная неправда. Я бы на вашем месте постыдился признавать что-то плагиатом без подробного изучения. Фу. Я, конечно, довольно критично обозвал Вашу статью отредактированной версией статьи David A. Wheeler. Нашлась и первоначальная статья: http://www.libertarium.ru/libertarium/freestate А также ссылки на ЕС проекты в области свободного ПО. http://www.libertarium.ru/libertarium/freestate-proj Прошу указать какие все-таки источники были использованы. PS: Прошу не судить строго, если что не так. В следующий раз, г-н Woland, когда будете кого-то обвинять (или просить после этого) , потрудитесь подписаться своим настоящим именем. Rgrds, Алексей Новодворский.
Re: OpenOffice
Vlad Harchev wrote: Свободные ttf включены в нашу сборку OOo и их не надо устанавливать дважды. Если они Вас устраивают -- отлично, если нет -- ждите, работа над ними идет, хотите -- присоединяйтесь. Если хотите работать с ttf от MS -- получайте букет проблем (легко разрешимых: впрочем, особенно если их брать с сайта MS, а не из дистрибутива Win). Проблемы эти связаны с лицензией MS и не зависят от разработчиков OOo и Debian. Проблемы конечно только лицензионного плана? Да. Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. А можно поподробнее про парсер afm от adobe? Почему они неприемлимы (с технической точки зрения)? Просто парсер от adobe не может быть неправ - все что он делает - строит по afm С-шные структуры, без каких-либо интерпретаций имен глифов и encoding. IMHO в укор ему можно поставить только то, что он не делает что-то кроме вышеописанного. Парсер не виноват, конечно. Виноваты программисты, которые берут из него вектор кодировки, не имея ни малейшего понятия о Unicode ps-шрифтах (очень-очень многие считают, что таких просто нет). Если бы в структуру добавить unicode каждого глифа, то все были бы счастливы. Rgrds, AEN
Re: OpenOffice
aen wrote: Vlad Harchev wrote: Свободные ttf включены в нашу сборку OOo и их не надо устанавливать дважды. Если они Вас устраивают -- отлично, если нет -- ждите, работа над ними идет, хотите -- присоединяйтесь. Если хотите работать с ttf от MS -- получайте букет проблем (легко разрешимых: впрочем, особенно если их брать с сайта MS, а не из дистрибутива Win). Проблемы эти связаны с лицензией MS и не зависят от разработчиков OOo и Debian. Проблемы конечно только лицензионного плана? Да. Не понял сразу Ваш вопрос, отвечу подробнее. Корень проблемы -- лицензия, но суть ее в том, что в системе появляются заменители MS ttf с теми же именами. Они якобы необходимы для документов, импортиремых из MS Office. Пример -- Abi, другой пример, правда из RH, -- варезные (это в RH!) шрифты Peter Soos из пакета ISO8859-2-fonts. Конечно, некоторые умные офисы, даже если не найдут Times New Roman, подставляют Times, но тут-то на его месте оказвается алиас на NimbusRomanNo9, который в стандартной поставке не содержит кириллических глифов. А даже если содержит, то большинство программ будут рендерить его с метриками от Adobe. В общем, если у кого-то есть знакомые дизайнеры шрифтов -- просите их поработать над шрифтами URW/Вали Филиппова. Я уже нашел двоих, но работы много. Проблема в том, что рендеринг Type1 и, отчасти, ttf в XFree, Win и MacOS сильно различается и то, что хорошо смотрится в Win, в Linux будет криво (и наоборот). Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. А можно поподробнее про парсер afm от adobe? Почему они неприемлимы (с технической точки зрения)? Просто парсер от adobe не может быть неправ - все что он делает - строит по afm С-шные структуры, без каких-либо интерпретаций имен глифов и encoding. IMHO в укор ему можно поставить только то, что он не делает что-то кроме вышеописанного. Парсер не виноват, конечно. Виноваты программисты, которые берут из него вектор кодировки, не имея ни малейшего понятия о Unicode ps-шрифтах (очень-очень многие считают, что таких просто нет). Если бы в структуру добавить unicode каждого глифа, то все были бы счастливы. Добавлю и здесь. Когда я делал патч для печати i18n в Mozilla, то времени на чтение 900-страничной книги от Adobe не было и пришлось пойти своим путем. Вместо обычной утомительной генерации многих (в общем случае) векторов кодировки (по сути, собственных шрифтов внутри ps-файла), что очень неприятно для текста, содержащего много разных Unicode-глифов, я воспользовался функцией вывода глифа по его имени (glyphshow). Почему-то ей никто не пользуется, а, между тем, выходной ps получается исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Может быть, это будет полезно тому, кто занимается интернационализацией печати. Rgrds, AEN Rgrds, AEN
Re: OpenOffice
Hi! Viktor Vislobokov wrote: Привет всем! Чего-то я не пойму про эту поделку. Непоняток просто куча 1. Пишу по-русски, буквы налазят одна на другую так, что смотреть на это просто страшно. Пишу этим же шрифтом по-английски. Все нормально! Проблемы с метриками глифов, отличных от Type1. Определите замену шрифтов или свои стили. В комплект входят свободные ttf Вали Филиппова на основе URW, называются URW . с L на конце. Приличные. 2. Где-то вообще можно задать/изменить те шрифты, которые используются для меню, кнопок и т.д. поскольку там OO может выбрать такой шрифт, что прочитать что-либо становится невозможно Читайте README на ftp.altlinux.ru. Изменить сейчас это нельзя. По умолчанию используются шрфиты Arial или Helvetica в microsoft-cp1251. 3. Беру Unicode TTF шрифты из Windows 2000. Устанавливаю их через spadmin. После этого OO вообще с ума сходит. Все буквы в меню в виде ___ ___ __ все подменю и диалоговые окна складываются чуть ли не в трубочку. Что такое? Почему? Если у Вас Savage, то надо установить XFree поновее. ttf надо установить в X и в OOo. Убедитесь, что другого Arial у Вас в системе нет, и что в каталоге с ttf есть ссылка на encodings.dir , а в fonts.dir описаны шрифты в microsoft-cp1251 Rgrds, AEN Используется последний OO от Alt-Linux. Виктор
Re: OpenOffice
Anton Petrusevich wrote: On Sun, Feb 24, 2002 at 03:34:55AM +0300, aen wrote: ttf надо установить в X и в OOo. Убедитесь, что другого Arial у Вас в системе нет, и что в каталоге с ttf есть ссылка на encodings.dir , а в fonts.dir описаны шрифты в microsoft-cp1251 Кривь какая. Всю эту бодягу вообще планируется фиксить? Или как обычно вам надо -- вы и делайте? Как обычно -- у кого? Подробнее, пожалуйста. Почему шрифт надо ставить в два места? Свободные ttf включены в нашу сборку OOo и их не надо устанавливать дважды. Если они Вас устраивают -- отлично, если нет -- ждите, работа над ними идет, хотите -- присоединяйтесь. Если хотите работать с ttf от MS -- получайте букет проблем (легко разрешимых: впрочем, особенно если их брать с сайта MS, а не из дистрибутива Win). Проблемы эти связаны с лицензией MS и не зависят от разработчиков OOo и Debian. Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. Rgrds, AEN
Re: OpenOffice
Anton Petrusevich wrote: Нормальная идея. Если мы не можем нормально жить с Type1, то и фиг с ними, у меня почти все шрифты в системе ttf, ничуть не жалею. MS создала хорошие наборы шрифтов, MS купил. Создал Monotype. раздает их бесплатно(э... про лицензию не копенгаген), почему бы их не пользовать? Включить в дистрибутив инсталлятор шрифтов с интернета, да с других мест (локальная винда, сетевой диск) может даже можно положить на диск с non-free? Инсталляторы есть, а вот на диск класть нельзя по условиям лицензии. Потому нельзя сделать эти шрифты основными by default. Rgrds, AEN
Re: xkb
Ilya Anfimov wrote: Это Xkb vs Core Protocol, но при чем здесь утилита xmodmap ? Во-первых это описание Xkb. Достаточно подробное. Спасибо, но мы не о том. Да и, честно говоря, читал я его :-) А xmodmap -- при том, что xmodmap это Core Protocol в чисто виде. Я привел Вам несколько аргументов, подкрепленных реальными примерами, в пользу того, что это не так. И просил примеров от Вас. Еще раз: Core Protocol не работет с keysyms. Вообще не рабоатет. xmodmap -- работает. Нынешний xmodmap работает как с Core Protocol, так и с xkb. В первую очередь -- расширенная серверная логика по управлению состоянием модификаторов, LED и языковых групп, стандартное хранимое на сервер описание типа клавиши и её поведения при различной комбинации из Shift и CapsLock, mousekeys -- для управления мышью с клавиатуры, расширение серверной (кажется) логики для удобного ввода людям с ограниченными возможностями (залипание всяких shift/ctrl, не реагирование на несколько случайно нажатых клавиш). Кроме того, в получившейся раскладке обычно вообще бывает всякий бред по поводу управления состоянием сервера и модификаторами. Пожалуйста, пример. Все описанное Вами у меня работает после загрузки xmodmap -pke. Точно так же, как и без xmodmap -pke? Тогда не удивительно. Я не знаю точно и вполне могу поверить, что xkb остаётся включённым и в примерно таком же состоянии, как и без xmodmap. Но в таком случае советовать xmodmap -pke как загрузчик xkb-раскладки довольно бессмысленно. О! Кстати, попробовал это на машине. ~/.xkb я здесь уже приводил. xmodmap -pke, затем xmodmap имя_файла. На русский после этого переключиться можно, обратно -- никак. При это shift в русском снесло начисто. Странные у Вас настройки. Все отлично работает Не нужно это приложениям в compatibility mode. С каких это пор Core Protocol стал работать с keysyms? Не знаю. Подозреваю, что X11 работает весь с ними. А вы отключите Xkb и посмотрите. Спасибо, я достаточно лет проработал без Xkb. И в целом представляю себе Core Protocol, а так же как и для чего планировались keysyms. Так вот, могу заявить, что keysyms в Core Protocol есть. Более того, они там есть всегда и не зависимо от раскладки или наличия xkb. Клавиша в любом случае транслируется из Keycode в keysym. Проверить просто: XkbDisabled. (Под `X11 работает весь' я подразумевал, что на X11R5 я их видел, что было раньше -- не знаю). Вы хотите сказать, что Core Protocol в X11R5 изменился? Как и куда они съедут? Раз на раз не приходится. Вот только что задался этим вопросом, и посмотрел в XKBProto -- как и куда они съедут. Там пара страничек этому посвящено. Особенно обнадёживает первый абзац из этой пары страничек. Примерно то же, что я и говорил: мы что-то сделали, чтобы это как-то работало, но в целом ничего не гарантируем и работает это не всегда. Вообще это в основном чтобы всякое старьё из-за мелочей не ломалось. Простите, но документацию я тоже читал. Она не о том. И местами устарела. Еще раз: я полагаю, что xmodmap есть просто утилита для отображения и изменения раскладки, которая не привязана к Core Protocol и не отключает Xkb. Конечно, она не управляет всеми Она привязана к Core Protocol. Она изменяет раскладку, описанную в Core Protocol. Средствами этого самого Core Protocol. Да, xkb она как оказалось не отключает. Именно. функциями xkb, но при указанном использовании мне не удалось увидеть то, что она портит. И что? Это аргумент в пользу того, что этого нет или хотя бы редко встречается? Главное -- даже если она ничего не портит, то и не делает того, что требовалось. Напоминаю, что тербовалось: индивидуальная раскладка для пользователя. Приведите, пожалуйста, пример, когда этой цели нельзя достичь при помощи xmodmap и наш спор закончится. Rgrds, AEN
Re: xkb
Hi! Ilya Anfimov wrote: а лишь универсальная утилита управления клавиатурой. Загрузите нужную раскладку xkb (например, посредством setxkbmap), а затем распечатайте ее в формате xmodmap: xmodmap -pke mykeyb Грохнув все расширения, относившиеся к xkb. Точнее, все расширения, которые не отображены на Core Protocol keyboard han- dling. Интересно, какие? С каких это пор Core Protocol стал работать с keysyms? Гляньте на xmodmap -pke . Или просто оставьте в .xmodmap определение ровно одной клавиши. У Вас будет переопределена только она, все остальное останется как было. Файл mykeyb под именем .xmodmap положите в домашний каталог. И получите сервер без xkb. Отключить xkb можно только при помощи XkbDisabled. Rgrds, AEN
Re: Лицензии на шрифты.
Hi! Fedor Zuev wrote: Не помню точно, где, то ли здесь, то ли в locale некоторое время назад обсуждался вопрос об авторском праве на шрифты, и, в частности, продукция фирмы ParaType. Так что, думаю, многим подписчикам будет интересно. На днях обнаружил замечательную вещь. _И_ по старому советскому законодательству, _и_ по классификации ВОИС (а значит почти наверняка и у нас сейчас) шрифты (начертания шрифтов, или физически, шрифтовые формы), относятся не к обьектам авторского права, а к так называемым промышленным образцам. Что означает: 1) срок действия исключительных прав - не жизнь автора + 50 лет а, максимум, 15 лет. 2) исключительные права возникают не по факту создания, а только при оформленном патенте. Это весьма спорно. У нас сейчас другое законодатльство. Если хотите подробностей -- напишите Вале Филиппову ([EMAIL PROTECTED]), у него есть все документы. И шрифты свободные он делает. Таким образом, ParaType своими террористическими заявлениями об авторских правах на шрифты сознательно или бессознательно дезинформирует публику. Никакими исключительными правами на начертания классических, советских еще времен, шрифтов (созданных до 1987 года) они не обладают и обладать не могут. Да и исключительные права на их собственные разработки - тоже не факт, что надлежащим образом оформлены (патенты денег стоят). Патенты здесь ни при чем. Патентное и авторское право -- две большие разницы. Однако, ParaType обладает исключительными авторскими правами на _программы_ на языке описания шрифтов (PostScript, TrueType) в которых выражается каждый конкретный шрифт. То есть прямо так взять и спиратить паратайповские шрифты нельзя. Но! Обратите внимание - _на программы_, но не на содержащуюся в этих программах фактическую информацию о начертании шрифта. Таким, образом, если извлечь из ParaType-овских шрифтов эту информацию и затем на ее основе создать другой шрифт (программу) того же начертания - то, IMHO, это все будет совершенно законно. Не вполне так. Если Вы возьмете достаточно старые начертания и запрограммируете их, то все будет чисто. Тем более, что почти все кириллические гарнитуры достатчоно старые. Если же поступить так, как вы предлагаете, то вопрос спорный и зависит от законодательства. Европейское здесь весьма либерально, достатчоно повторить процедуру открытия и сохранения файла в разных редакторах пару десятков раз и суд не придерется. А вот американское - гораздо строже. Paratype, конечно же, мухлюет. Но не думаю, что это повод с ним бодаться. Лучше сделать все свое, -- теперь это возможно. Rgrds, AEN А на практике, насколько я понимаю, для этого достаточно загрузить в редактор шрифтов, чего-нибудь незначительное поправить и затем сохранить. :-)
Re: ReiserFS
Vlad Harchev wrote: On Sat, 22 Dec 2001, Anton Petrusevich wrote: On Sat, Dec 22, 2001 at 05:59:00PM +0400, Vlad Harchev wrote: И еще советы бывалых людей: ни за какие коврижки не связывайтесь с reiserfs. Будете сильно жалеть. Ой не надо. Ни разу не имел проблем с reiserfs, хотя пользовал ее со всремен, когда там еще журнала не было. Статистика - вещь упрямая.. Значит просто повезло.. Есть ложь, наглая ложь и статистика :-) Если серьезно, то эксперименты, которым я доверяю, не подтверждают неустойчивость RFS. Они выявляют возможность проблем с ext3 и, особенно, JFS. К сожалению, я сейчас не могу дать ссылку на описание методики и сами тесты, о которых рассказывал Александр Боковой, но, скорее всего, их можно будет публиковать в январе . Преимущества RFS в скорости проявляются при размещении журнала на другом устростве, нежели fs. Увы, эта возможность не входит в stable ветку , а патч, реализующий ее, потерял актуальность. Rgrds, AEN
Re: холивары (fwd)
Wartan Hachaturow wrote: On Fri, Nov 23, 2001 at 09:51:46PM +0200, Vladimir N.Velychko wrote: BSD бы было, да и Linux kernel не Столлманом написан. А что есть ядро без софта? Творчество студента Линуса? ;= А что, софт Столлманом написан? Не смешите мои тапочки. Все, что он написал в 80-лохматых годах уже не один десяток раз переписано и переделано. Вартан, гляньте Changelog emacs. Того, что Столлмен написал в 70-80-90 хватит на сотню. Во второй половине 90-х у Столлмена болели кисти рук. Профессиональная, знаете ли, болезнь. Дай Бог, чтобы у Вас не случилось. Вы действительно считаете, что писать код -- единственное занятие программиста? Простите, но из Ваших писем складывается впечатление, что работа -- это как у прапорщика из анекдота : Что тут думать? Трясти надо! FSF -- некоммерческий фонд, именно потому деньги у него есть. Cash, а не бумаги, так как именно бумагами некоммерческие организации владеть не могут, а вот заниматься коммерцией -- на здоровье. Начались эти деньги с того, что Столлмен получил стипендию гения, а недавно вот японцы почти мильон подкинули. На мерс хватит. Посмотрите, кстати, не подкидывал ли чего этот фонд Debian'у? Я лично очень уважаю Столлмена, у меня есть на это веские причины. Думаю, не я один. И хотя бы поэтому прошу Вас быть корректным по отношению к этому челоееку, которого Вы хаите за глаза. Есть претензии -- напишите ему. Он отвечает на все письма. Rgrds, AEN
Re: перевод
Victor Wagner wrote: Вообще-то во-первых, pgp применяется не только для ЗАшифтрованияч (даже если этот термин корректен вне узкоспециального контекста) но и для РАСшифровывания. А электронная подпись, строго говоря, ни тем, ни другим не является, хотя несомненно является криптографической технологией. Поэтому я бы сказал криптографическая програма pgp. И сразу признаете себя нарушителем закона :-) Лучше какая-то там программа pgp. Rgrds, AEN
Re: перевод
Alexey Vyskubov wrote: проблема: слово зашифрования. я предлагаю применять термин шифрования. Это слово взялось не с потолка. Правильный термин -- зашифрование. Правильность его была установлена путем консультации с экспертом по криптографии. Не лучше ли было обратиться к лингвисту? :-) Rgrds, AEN
Re: KDE2
Victor Wagner wrote: По-моему глупо надеться что оно будет работать нормально.. KDE2 вроде как не поддерживает несколько сессий для одного юзера на одной машине (панель и меню отказываются во второй сессии работать). Да А мне не нужна панель и меню во второй сессии. Плохо что они не работают в единсвенной KDE сессии, если в какой-то другой (не KDE) сессии запущена хотя бы одна KDE application. А это не так. Rgrds, AEN
Re: utf8
Max Kosmach wrote: On Tue, Dec 05, 2000 at 09:07:59PM +0300, aen wrote: Alexey Zagarin wrote: Почитал тут Unicode-HOWTO на linuxdoc.org.. Стало любопытно, а не делает ли кто-нибудь у нас юникодную локаль, типа ru_RU.UTF8, например? Вроде бы всё уже готово: и ядра 2.4.0-test юникод поддерживают, и X'ы 4-ые.. Или это всё нафиг не нужно?! При установленной glibc-2.2: # localedef -i ru_RU -f UTF-8 /usr/lib/locale/ru_RU.UTF-8 Вот она и сделана. Угу... bob:~# localedef -i ru_RU -f UTF-8 /tmp/ru_RU.UTF-8 /usr/share/i18n/locales/ru_RU:1927: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1928: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1929: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1930: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1931: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1932: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1933: LC_COLLATE: syntax error /usr/share/i18n/locales/ru_RU:1934: LC_COLLATE: syntax error no output file produced because warning were issued bob:~# Я конечно понимаю, что warning - это не error, но тем не менее. Тем не менее _это_ можно игнорировать. Добавьте -c Если очень раздражает -- уберите строки 1927-1934 из ru_RU. Rgrds, AEN
Re: utf8
Max Kosmach wrote: Тем не менее _это_ можно игнорировать. Добавьте -c Если очень раздражает -- уберите строки 1927-1934 из ru_RU. Не очень Просто интересно по какому поводу ругань и нельзя ли это все официально пофиксить? Это попытка описания некторого свойства арабской азбуки. Арабская locale включена впервые и с ней, видимо, есть проблемы. Для того, чтобы это фиксить, явно нужен знаток арабского. Rgrds, AEN With MBR Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
