Главная

Собираем файловый менеджер Midnight Commander 4.6.1


Для сборки необходимы:

Далее открываем файл /mc–4.6.1/config/config.guess и добавляем в него следующее после 1189 строки:


    BePC:Haiku:*:*) # Haiku running on Intel PC compatible.
    echo i586-pc–beos
    exit 0 ;;


Затем открываем configure файл, находим строку “for lib in bsd socket inet; do” и добавляем в неё параметр “network” до точки с запятой для обеспечения работы с сетью (типа ftp), сохранив, выполняем конфигурирование (должен быть активен GCC2) со следующими параметрами: «configure -–prefix=/boot/common --with–screen=ncurses”, запускаем сборку “make” и установку “make install”.

Запускать рекомедуется со следующим ключом: “mc -a” или добавить в файл /boot/home/.profile строку alias mc="mc -a” (с кавычками) из–за некорректной псевдографики, а чтобы mc стал цветным, в том же файле прописываем строчку «export TERM=xterm–color”.

UPD. Все изменения в файлах можно проще и быстрее сделать с помощью этого патча, применять также как для Psi.

Написано с непосредственной помощью Сяржука Жарского.

Патчик бы под

Патчик бы под эти хаки в конфигуре сделать. Вечером соображу. ;–)

«патчик

«патчик к конфигуре» ?? лучше нормально autotools допилить, чтобы ./configure с дефолтными ключами без патчиков выдавал не ересь, а рабочую конфигурацию. А то приходится то с --build=i586-pc–haiku / i586-pc–beos /i586–pc играться, то в libtool хаки править, чтобы компилировал/собирал без -lm -lc
Нормально работающие autotools — это когда конфигура «из коробки» выдаёт разумно настроенный config.sub

Может кому

Может кому и лучше автотулзы попилить, но в данном случае задействован старый армейский принцип -"нужно, чтобы работало, вперёд — рожай!" «Взял сорцы там–то, приложил патч такой, задал команду такую–то. Пользуйся.» Всё чётко и ясно.
А на m4 учиться разговаривать честно говоря лень. И за всё «человечество» впрягаться тоже лень. Мы уж по–стариковски в кернел дебаггере на дампы, под чаёк подивимся вместо этого. ;–)

А не проходит

А не проходит ли этот фокус с пререлизами mc 4.7?
Если да — возможно, есть смысл переслать патч нынешним разработчикам?

он даже с 4.6.2

он даже с 4.6.2 не проходит, и с 4.6.1 пропатченым на утф–8 не проходит. Не собирается что–то из slang функций. Хотя кое–кто и собирал 4.7. ;–)

Проходит, даже

Проходит, даже очень. На неделе собрал mc 4.7 pre4. Результаты считаю неплохие если учесть, что работает отображение рамок как положено, работает ftp, повозился с subshell'ом — тоже заработал.
Перекодировка тоже работает, скины работают. На пока меня все устраивает. Собирал: slang–2.2.2 с terminfo database ( немного пропатчил ), glib–2.22.2 (haiku ports), pkg–config (haiku ports).
Haiku скомпилена самостоятельно trunk GCC4 only.

Ждём патчик

Ждём патчик с «инструкциями» если не жалко отдавать. :–) Можно на мыло: zharik-хрю-gmx–li. Ну фтп и в нашем работает, а что с саб-шеллом–то? А по зип–файлам он ходит? ;–)

По

По зип–файлам ходит (править в extention file). Все выложу на след неделе если интересно. Теперь о том, что работает. Не работает интернализация, меню на английском, не срабатывают некоторые сочетания клавиш.

Да, Дмитрий,

Да, Дмитрий, конечно–же интересует! Я думаю вообще имеет смысл отправить патчи разработчикам. Или хотя–бы на ports.haiku–files.org закоммитить. А интернационализация там через gettext идёт? Что по поводу рамок — мы вообще считали, что это недоделка в гаечном терминале. Очень интересно посмотреть на вашу работу и убедиться, что мы ошибались. :–D А сочетания клавиш нужно по месту смотреть — возможно гаечный инпут–сервер что–то перехватывает на свои нужды?

http://bebits.com/app/810 А

http://bebits.com/app/810
А вы случайно не «однофамилец» автора того самого порта? ;–)

Нет

Нет не однофамилец. А с тем портом получилось все очень печально — исходники были утеряны в связи с поломкой ЖД, сделать все снова на тот момент времени не было возможности. Про рамки — гаечный терминал, как я понимаю, не держит эту фичу. В мс поддержка скинов позволяет отображать что угодно — хоть одинарные, хоть двойные рамки. Со временем я думаю доработают и терминал.

Да, гаечный

Да, гаечный терминал ещё далёк от совершенства. :–\

Патчи выслал

Патчи выслал на мыло. Если не трудно выложи здесь. Спасибо

export

export LANG=ru_RU.UTF–8 и в MC все по–русски :)

>Да, гаечный

>Да, гаечный терминал ещё далёк от совершенства. :–\

а какой–либо другой есть? А то надоело в vim Ctrl–L нажимать, перерисовывается какая–то ересь при пролистывании

Есть MuTerminal,

Есть MuTerminal, должен работать в Haiku. Ну и XTerm, конечно, но не уверен, что X11 заработает в Haiku.

А что за порт

А что за порт вим–а? Из пакажей? В гуишном из принципа не сидим? :–)

гуишного

гуишного седьмого ЕМНИП, нет. Вот допилить бы порт GTK2..

Уууу… Ваша

Уууу… Ваша «информированность» поражает. :–D Дело в том, что вы сейчас общаетесь с человеком, который вернул седьмому виму гуй под гайкой. И порт этот уж как полгода доступен в составе опциональных пакажей т.е. вполне официально. :–)

А ваше намерение насчет ГТК2 серьезное?

вот спасибо,

вот спасибо, добрый человек. А то я гайкой интересуюсь эпизодически, и сложно бывает отследить текущее «состояние дел», и официальную «линию партии» :–)

> А ваше намерение насчет ГТК2 серьезное?

надо же чем–то себя занять на новый год. Посмотрю, пособираю — вдруг что из этого получится. Насколько я понимаю, достаточно портировать gdk и gdk–pixmap.

хм… парни

хм… парни с портом qt себя уже целый год «занимают» в много–подходном режиме. :–) Кстати один из них занимался портом ГТК2 до того, как решил помочь с QT. По хорошему с ним бы переговорить для начала. Зачем с нуля–то начинать? Да и вряд–ли с наскока у вас что выйдет — и как всегда весь пар уйдёт в свисток. :–(

ПС: Зарегистрировался–бы ты, ёжик. ;–)

Патчик получен?

Патчик получен?

Да,

Да, на следующий день. Как я уже косвенно описывал эту опопею — он хочет slang, slang хочет libtool — гайкопортер пыхтел три часа, загадил мне полраздела и потом банально обкакался — не смог собрать. На том мой лимит времени и терпения на всё это барахло и закончился. :–\

да ещё, если

да ещё, если прописать в .profile команду

export TERM=xterm–color

то этот командир будет в цвете.

Забыл про это

Забыл про это совсем, добавлю сейчас.

както

както правильно и сложно описано…

=)

проще както собирал, ей ей)

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

а если просто

а если просто выложить готовый пак с бинарниками? распаковал и пользуй

До появления

До появления полнофункциональной системы пакажей/портов в Гайке подобная сборка из исходников мне видится наиболее оптимальным вариантом по следующим причинам:
1) Вероятная несовместимость с библиотеками уже установленными в системе и с косяками в самом системе.
2) Желающих работать в «службе поддержки» и выяснять вариации пункта 1) на постоянной основе как правило нет. Времени и желания на такое бесполезное (для разработчика) занятие не предвидится.
3) Опубликовал — отвечай. Способность собрать программу самому по чёткой инструкции есть своего рода «вступительный ценз» — если кто–то не способен даже на это — время потраченное на консультирование его определенно уйдёт впустую. Пусть ждет систему пакажей.
4) Система динамично изменяется — несовместимость из пункта 1) может возникнуть уже завтра. Да, мы не даем вам «рыбу», но мы даем вам удочку, чтобы ловить эту «рыбу» тогда когда она вам потребуется.

Так что без обид, парни, хотите плюшек — придется потрудиться.

это понятно.

это понятно. просто лень, да и некогда особо самому собирать ;)

а что, систему пакаджей уже начали писать? вот было бы круто, если бы оно было по типу линуксовых реп (с метапакетами и прочими прелестями). отметил галочкой нужные проги и жмякай «хочу». пакеты сами высосутся и поставятся и за обновлениями и конфликтами софта система будет следить, а не юзер. я из–за этого на линух и ушел с мастдая.

Некогда? Да,

Некогда? Да, времени это отнимет невероятно много — аж цельных 5–10 минут! :)

Пролетало

Пролетало в листах, что кто–то изъявлял желание. Так что может кто–то и пишет.

>1) Вероятная

>1) Вероятная несовместимость с библиотеками уже установленными в системе и с косяками в самом системе.

несовместимость чего с чем? Софта, поставленного из бинарников между собой? Нормальный пакетный менеджер должен это всё разруливать

>2) Желающих работать в «службе поддержки» и выяснять вариации пункта 1) на постоянной основе как правило нет. Времени и желания на такое бесполезное (для разработчика) занятие не предвидится.

возьмём к примеру, Gentoo. «конфигурация системы сборки» = cat /etc/{make.conf,/portage/package.{use,mask,keywords,unmak}} или emerge -–info. Можно поставить «слотовый» ебилд — рядом gcc 4.4.2 и 4.3.4, например, binutils с gold linker и с обычным ld, php4 и php5 и переключаться между ними через gcc–config, binutils–config, и т.п.

Хотя более правильный подход — это система вроде Nix OS, nixpkgs. Пакетный менеджер на функциональном языке программирования, без побочных эффектов — то есть, все конфликты автоматически не допускаются, на уровне дизайна пакетного менеджера. А конфиги, изменяемое состояние, настройки «пакетов» являются логическими-формулами–предикатами в пакетном менеджере, то есть перегенерируются из функциональных программ. То есть, всегда можно откатиться на предыдущее состояние.

Вариант «для бедных», с «палками и верёвками» — поставил хайку из флешки, сделал в корне git init/git add ./ git commit -m “initial nightly SVN r…” /git tag initial — и имеем «версионированную ФС». Я так сделал на чистом разделе — 600М система, 200М папка .git в корне раздела.

Очень пригодилась, когда наткнулся на глюк с шрифтами — копируем папку с .ttf фонтами из винды, потом выбираем красивые и на некоторых шрифтах терминал сворачивается в кучку — неправильно читаются метрики шрифтов. В меню приложений не прорисовывается ни одна надпись, в файрфоксе тоже не видно ни одного шрифта. Соответственно, не можем сменить назад на дефотлные в окошке preferences/fonts — кнопки, меню и комбобоксы не прорисовываются.

фигня вопрос — удаляем /home/…/font settings, и шрифты через git reset HEAD -r initial — и имеем нормальную, «чистую» систему.

>3) Опубликовал — отвечай. Способность собрать программу самому по чёткой инструкции есть своего рода «вступительный ценз» — если кто–то не способен даже на это — время потраченное на консультирование его определенно уйдёт впустую. Пусть ждет систему пакажей.

Просьба указывать в таких инструкциях всю информацию, нужную нормальному пакетному менеджеру — версию nightly сборки/gcc/autotools/пакетов/ключей ./configure и CFLAGS, c которыми точно собираются пакеты. Чтобы облегчить пункт 1).
То есть да, инструкция нужна *чёткая*, *конкретная* — что качать, как ставить, каких версий, или не нужна никакая вообще.

>4) Система динамично изменяется — несовместимость из пункта 1) может возникнуть уже завтра. Да, мы не даем вам «рыбу», но мы даем вам удочку, чтобы ловить эту «рыбу» тогда когда она вам потребуется.

Ах, как это напоминает грабли в Gentoo при обновлении профиля/тулчейна/мажорных версий софта и замаскированных пакетов. Тоже случаются грабли, тоже время от времени «портедж» ломается в основной ветке. Но, благодаря пониманию и гуглению и общей понятности пакетного менеджера/системы сборки понятно, где сломалось и как починить. Поэтому, когда ломается — не смертельно.

То есть, мне кажется в Хайку имеет смысл портировать нормальный source–based пакетный менеджер вроде emerge/paludis/nixpkgs/pkgbuild из арча и собирать уже им, а не изобретать велосипед.

>1) Вероятная


>1) Вероятная несовместимость с библиотеками уже установленными в системе и с косяками в самом системе.
несовместимость чего с чем? Софта, поставленного из бинарников между собой? Нормальный пакетный менеджер должен это всё разруливать

Так я о том же и говорю. Зачем мне тратить время на разгадывание того, почему у очередного несчастного мой билд не запускается? Мне это занятие совершенно не интересно. ;–) А менеджера пакетов — как я уже несколько раз говорил — в гайке пока нет. В силу этого факта — остается наиболее экономичный (для разработчика) вариант — самосбор.


То есть, мне кажется в Хайку имеет смысл портировать нормальный source–based пакетный менеджер вроде emerge/paludis/nixpkgs/pkgbuild из арча и собирать уже им, а не изобретать велосипед.

Возникает резонный вопрос — если их так много, следовательно значительная масса народу каждым из них в отдельности недовольна. Зачем гайке несовершенные решения? Нужно взять все лучшее от каждого и сделать что–то одно. К черту такое «разнообразие» — менеджер пакетов будет работать стабильно лишь тогда когда он будет единственной сущностью обеспечивающей целостность взаимосвязей шареных компонентов.

>Зачем гайке

>Зачем гайке несовершенные решения? Нужно взять все лучшее от каждого и сделать что–то одно

Здесь хотелось бы определить, что значит «несовершенное» решение, и какой в чём лучше. Единообразность полезна, да — но она должна быть правильной, расширяемой. А то можно и SRPM/debsrc притащить, но это ведь полная ерунда по сравнению с вышеупомянутыми, с точки зрения функциональности. Она годится когда процесс уже налажен, но когда идёт самосбор нужно что–то более умелое.

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

необязательно. В Paludis, к примеру, есть утилита importare и понятие foreign installed packages. Когда можно взять тот же RPM, или zip, распаковать бинарники и сказать пакетному менеджеру «эти файлы образуют пакет версии x.xx категории yyy-zzz/www–vvv»

В exherbo есть понятие «виртуальный не написанный ещё пакет» — пакета нет, а зависимости отслеживать надо.

То есть, paludis в этом смысле выше на полголовы остальных source–based пакетных менеджеров, — им можно описать зависимости во внешней системе, которых нет среди пакетов. Ну и обычные плюшки source–based — автоматически выкачивать исходники, распаковывать, накладывать патчики, конфигурять с нужными ключами USE–флагами, и т.п.

Да я и имел

Да я и имел ввиду, что нужно взять всё самое лучшее из существующих на данный момент систем. ;–) А смысл моего тезиса о несовершенстве таков — если существует множество вариантов пакет–менеджеров, значит ни один из них не идеален настолько, чтобы занять всю нишу целиком. Специфика решаемой задачи ИМХО позоволяет создать универсальный инструмент для решения этой задачи. Если никто из перечисленного вами зоопарка не съел остальных — значот они все в равной мере слабы. А нам нужен такой «зверь», который пожрёт всех — только и всего. Без вариантов.

Кстати, по поводу портирования линуксятины на гайку можете ещё глянуть на TiltOS — http://tiltos.com/drupal/. Проект ведомый очень самостоятельным польским товарищем. Думаю вам будет с ним о чём поговорить. ;–)

> А смысл моего

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

ой ли. А с чего бы вдруг решение из одной ниши захотело и осилило забороть решение из другой ниши? На эту тему есть хорошая книжка «Дилемма инноватора», которая объясняет, почему самые лучшие технологии не всегда просто могут выжить и уж совсем необязательно «всех победят». Просто есть disruptive innovation и supportive innovation — одна хочет всех победить и изобретает велосипед, вторая стоит «на плечах гигантов».

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

> Специфика решаемой задачи ИМХО позоволяет создать универсальный инструмент для решения этой задачи.

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

> Если никто из перечисленного вами зоопарка не съел остальных — значот они все в равной мере слабы. А нам нужен такой «зверь», который пожрёт всех — только и всего. Без вариантов.

такого идеала ждать можно бесконечно долго и ещё дольше, а хочется уже сейчас «вступать & компелировать», и делать это не мучительно больно ручками, а автоматизированно как в той же генте с source–based пакетными менеджерами.

У гайки своя

У гайки своя ниша (пока что) — десктоп. Это уже накладывает ограничения на «размеры» ниши для её пакет–менеджера.

Да и вообще, я не та персона с которой обсуждают такие вопросы. ;–)

> Зачем

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

потому что если несчастный не накосячил с конфигурацией системы сборки/пакетного менеджера кривыми ручками, а пользуется «официальным» пакетным менеджером/тулчейном/настройками, то у него должен билд запускаться «из коробки». Если не запускается — это косяки тулчейна.

Например, почему не линкуется хелловорд, собранный DMD компилятором, собранном в соседнем топике — ругается на _d_throw@4 символ? Где–то косяк в скриптах линкера.

Когда хайка стала self–hosted, получилось это благодоря портированию кучки софта, определению и исправлению косяков в тулчейне. Сразу получилась отдача — уже можно «вступать & компелировать» ™.
Если что–то где–то не собирается — значит косяки с системой сборки.

Если есть что–то вроде emerge -–info == конфигурацию системы сборки можно определить автоматически, запостить на pastebin, сравнить с рабочей конфигурацией у другого пользователя, у которого «всё работает», и сделать всё это в полуавтоматическом режиме, с минимальным гаданием — диагностика соберётся автоматически. При этом тебе самому и время–то на гадание не нужно тратить — нужно просто обеспечить чтобы диагностика собиралась автоматом по глючной системе, по рабочей, и дальше сообщество само разрулит, если осилит.

Товарищ!

Товарищ! Вы меня за порты не агитируйте. :–) Я сам тут за них уже десятилетие всех агитирую. :–) И вы вообще читаете что вам пишу или как и я ваши только по первым строчкам? :–D Нету менеджера, а нету менеджера — не будет и скомпиленых моей рукой пакетов. Ждём менеджера.

> Ждём

> Ждём менеджера.

прям как народ ждал доброго царя, барина. Вот придёт барин и всех рассудит :))

А что пробовали из пакетных менеджеров–то, что подошло, что не подошло, и самое главное, почему? Официальным деревом портов пользоваться–то можно/сложно/невозможно? Почему оно не подходит? Какими фичами должен обладать «идеальный менеджер–гайковёрт» с точки зрения простого девелопера с портянками? Почему мы тут ручками компелируем, когда где–то есть пакетные менеджеры, порты и прочие блага цивилизации? :))

Хм. А с какой

Хм. А с какой целью интересуетесь?

А насчёт барина — это вы напрасно, у меня есть список задач и пакетного менеджера в нем нет. Во первых задача объемная и пожрет имеющееся время на многие месяцы вперёд. Во вторых мне эта тема не интересна в силу тривиальности. Я положил, что делать кое что более сложное будет поэффективнее для меня, системы и комьюнити. В третьих некоторое копошение на гайко–портах идёт и приходить туда со своим топором и махать, считаю не совсем корректным. Так что менеджер пакетов я оставляю тем, кто боится драйвера писать. :–)

Менеджер

Менеджер пакетов на Гайке не нужен. Даёшь нормальные либы! Даёшь нормальные проги! Даёшь нормалную Гайку!Вон чего нибудь типа БеОСового SoftwareValet – это другое дело.

Стихни!

Стихни! Без пакаж–менеджера не будет тебе нормальных либ. Ибо пакаж–менеджер как раз и призван чтобы пасти эти либы и не давать кривым апликациям обсирать жизнь нормальным программам. А твою возлюбленный Валет и есть зародыш пакаж менеджера.

Этот Валет

Этот Валет красивый и стильный. А зафинтилят какую нибудь скучную аля терминал на двух листах текста… зачем ещё один юникс? В Гайке надо найти свой путь „гайкувей“, и всё же под носом: lib папки разного уровня – остаётся только признать, что это есть и применять, а не всё с никсов копировать без разбору. Просто нехочется ещё одной бубунты с совсем этим мусором, где чтоб какую фигню установить…

Красивый

Красивый и Стильный, только не умеет ничего, кроме как прогу поставить и записать у себя что она поставлена. А вот элементарно снести её — это уже «не царское дело» для этого Стильного. Повторяю — линукс не в программах — линукс в головах.

Вон такая идея,

Вон такая идея, а не научить Гайку самoй находить нужную версию либы для изпользования? вон как она находит либы собраны с GCC4? a все эти версии (не системные) размещать в common/lib/
И весь пакадж менеджер тогда заключался бы, при отсутствии какой нибудь либы: Гайка отсылала бы на спец сайт, или прямо предлагала скачать и установить оттуда этакую либу (как счас это иногда делается wgetом, при установке некоторых программ). И скажем в common/lib/ ложились только либы с этого официального сайта. Далее, если какому девелоперу нажна какая новая или особеная либа, и он нехочет её добавлять на этот официальный сайт, он её может установить в папку lib своего приложения. Правда, при таком положении становится неясным, зачем нужна папка /home/config/lib – для экспериментальных пользовательских либок?

Вы чъи друзья?

Вы чъи друзья? Мои или медведя? (с) Зачем затруднять использование общечеловеческого достояния без особой на то нужды? Ты в курсе, что с винды что–то портировать практически невозможно? Ты хочешь чтобы и на гайку портировать что–то стало невозможно? А ты осознаешь тот факт, что без портированного gcc Гайка даже в том виде в котором она есть сейчас попросту не существовала бы? А вообще, по моему мнению, для всякого рода изобретателей велосипедов, в Аду имеется свой круг для экзекуций. Где–то между обжорами, блядунами и прочими гордецами. За растрату бесценного времени и ресурсов. Так что поосторожнее с идейками.

Непонимаю

Непонимаю в чём проблеммы, что с того плохого, что Гайка умела бы подбирать нужную версию либы? А ресурсы и время по любому будут истрачены. Зачем накладывать лишнюю работу на пользователя? Которая будет ещё и многоразовой.

Ты для начала

Ты для начала свою «рацуху» в мозгу оформи, чтобы её понять можно было — потом обсудим. Есть четкий алгоритм поиска модулей, какая директория просматривается первой, какая второй и т.д. Проблема [потенциальная] в том, что под именем libexpat.so может лежать разное — в т.ч. и линк на либу. А никак не в том, что система не может найти собственно libexpat. Грамотный пакет–менеджер контролирует ситуацию в целом и не допускает до подобных ситуаций. Правда махновщину в стиле drop and run таки придется забыть. И это zaebiste! :–)

Подумай

Подумай сначала, как ты будешь реализовать выбор нужной либы из десяти тысяч, лежащих рядышком в папке common/lib/. Я вот о чём: там (или в подпапках, неважно) будут свалены в кучу сто версий библиотеки SDL, 30 версий библиотеки jpeg, ещё 40 версий библиотеки PNG, восемь версий ещё какой–нибудь библиотеки… И у всех разные имена, чтобы их можно было держать в одной папке. Но программам–то на это наплевать, верно? Они ищут библиотеку по имени, а даже не по версии. На основании каких данных ОС должна предоставить программе библиотеку версии А, а не версии Б?

Иногда это можно выяснить на основании косвенных данных: программа обращается к функции, добавленной только в версии 0.3 библиотеки. Тогда понятно, что версии с 0.0.1 до 0.2.9 не нужны. Но как выбрать нужную версию из промежутка 0.3.0 до 1.3.5? А программа использовала какой–то workaround, который работает только в версии 0.4.2, — и, скажем, уничтожает все данные с жёсткого диска в других версиях библиотеки. (Оставим на секунду личность программиста, написавшего такой код). Ещё раз: на основании чего ОС должна решать, какую библиотеку предоставлять программе, если единственное, что знает программа, — это имя библиотеки?

С gcc всё же было проще. ОС знает, в какой версии компилятора была скомпилирована библиотека, и в какой версии компилятора скомпилирована программа, исходя, ЕМНИП, из анализа схемы бинарника.

Вон и я думаю,

Вон и я думаю, чем это думают програмёры пекущие несовместимые либы с тем же названием, или гсс++ который неумеет того, что умел его предшественик. Вообщем этот юниксовый мусор мне ненравится – безпорядок. И счас весь он перекачёвывает в папку common, кошмар! надо было называть эту папку /unix или /linux.

Повторяю:

Повторяю: проблема решается грамотным пакаж–менеджером и жестким руководством репозиторием портов. Я лично за десять лет пользования фрибсд–шной системой портов проблем с совместимостью библиотек не имел ни разу. То, что использованный тобой инструментарий не работал корректно говорит лишь о его несовершенстве, а не о якобы порочности самой идеи. Я и сам не в восторге от того, что чтобы собрать mc, нужно собирать slang который в свою очередь требует libtool. Эта информация и эта работа для меня лишняя и ненужная. Всё это должно отслеживаться и поддерживаться пакаж–менеджером без всякого отвлечения усера на неинтересные ему вопросы и задачи. А называть юниксовым мусором то, благодаря чему ты уже сейчас можешь пользоваться гайкой — это стопроцентное свинство под дубом. Так что не нужно делать красные и круглые глаза, или рефлекторно садиться от страха на жопу. Нужно брать задачу за рога и решать её как и подобает человеку. Дискуссия окончена.

Во многих

Во многих командах символ минуса заменился на "–" (тире) по причине особо одарённого движка qube.ru — их необходимо поправить ручками после копирования в терминал.

Движок как раз

Движок как раз особо одарённый. Ты не представляешь себе, какое это счастье, когда движок сам заменяет напечатанное на нормальные, читабельные знаки препинания, то есть минус на M–dash и N–dash, а знаки дюйма — на кавычки «лапками» :) Так задолбало в других местах вручную печатать Alt+0151, Alt+0150, Alt+0171 и Alt+0187. Другое дело, что внутри тэга <code> он этого делать не должен :)

На utf&ndash;8

На utf–8 это совсем не актуально (вручную печатать Alt+0151, Alt+0150, Alt+0171 и Alt+0187), даже на винде можно подравить клаву, чтоб вводила необходимые сибволы. Ну и на BeOS, HaikuOS это совсем просто. Эти навороты устарели на лет десять. Помеха, а не навороты.
PS
„«<>§в<в<^в°§вв°в^Вв°^ВВ^в°}"{…"Ев

–…}/Е}"…{}"'"*Е/в

–…/"…в

–/}"'Й”{в–М·ЕМ·вГв“Ев‘М·М·Е·МЕв®в»“ такие симбволы обычно в современных клавиатурных разкаладках находятся на 3 уровне (с алт или контрол), может быть ещё и четвёртый уровень (к вызывающему третий уровен клавишу доп. нажать шифт)

Вон

Вон как сдешний движок портит текст в utf–8, пытаясь его «осовременить» толи «приспособить».

Не должен,

Не должен, но делает :(

alias mc="mc -a"

alias mc="mc -a" добавленый в .profile также сэкономит 3 символа при запуске программы из терминала.

Добавил.

Добавил.

блииин

блииин супер!)!!!!!! супер!блииин супер!)!!!!!! супер!блииин супер!)!!!!!! супер!блииин супер!)!!!!!! супер! я дикий спамер))

А по&ndash;моему,

А по–моему, такой путь самособирательства программ ведет к линуксу.
------------------------------–
BeOS 5.0.5 BONE mini version, Celeron 500 MHz, RAM 320 Mb, GeForce 5200 128 Mb

Линукс &mdash;

Линукс — он не в программах, он в головах. К «линуксу» приводит загаживание мозгов примитивными левацкими идейками а никак не публикация инструкций по самостоятельной сборке программ.

А вообще, разверни тезис. А то непонятно, против чего ты выступаешь. Предлагаешь убрать эти инструкции и сидеть дальше в осточертевших за десять лет стенах гетто R5-Dano–Zeta? Да ведь никто тебя не заставляет что–то делать. Не нравится сам процесс сборки? Выше я уже изложил объективные причины почему на данный момент этот вариант оптимален — а повторяться не вижу смысла. Или ты против портирования приложений? В таком случае как поступать с тем фактом, что доля интересующихся гайкой пользователей на этой планете близка к нулю? И в силу этого факта отсутствия спроса на нативные гайко–приложения не будет и их разработки. Банально это НИКОМУ НА ДАННЫЙ МОМЕНТ НЕ НУЖНО. Никому из тех, кто способен принять такое решение или повлиять на его принятие. А жить- то хочется. И работать хочется уже сейчас. У тебя есть другие варианты? Озвучь! А священную битву «порты-vs–натив» предлагаю отложить до лучших времен, когда вышеупомянутый процент заангажированных пользователей перевалит хотя–бы за пятерку. Вот тогда наши носы получат хоть какую–то степень свободы чтобы иметь возуможность крутить их куда нам нравится а не держать в силу необходимости под железной подмышкой Фатума.

А я позволю

А я позволю себе согласиться с Digger`ом.

Одно из неоспоримых преимуществ BeOS по сравнению с Linux заключлось в том, что программы для BeOS распространялись в виде бинарников, готовых к употреблению. Не надо было искать требуемые программами версии библиотек, не надо было думать о конфликтах между ними (кто пытался заменить в Linux glibc, должен меня понять). Программа скачивалась, распаковывалась и работала.

Я не вижу ничего плохого в том, чтобы все библиотеки, которые нужны программе, загнать в папку lib, дабы программа не искала их по всей системе. Да, может быть, программа от этого разбухнет в несколько раз, но будем реалистичны: скачать 100 мегабайт в наши дни не сложнее, чем скачать 2 мегабайта. И гигабайт скачивается с той же лёгкостью. Место давно перестало быть проблемой. И, кстати, если у одной программы в папке lib будет версия 1.8 библиотеки, а у другой — 2.0, то всё по–прежнему будет работать. Лучше пусть у меня в двадцати разных программах будут 20 разных версий одной и той же библиотеки, что противоречит самой идее библиотек, но зато я не буду заморачиваться на тему того, как эти программы запустить.

Повторюсь,

Повторюсь, «линукс» не в библиотеках, а в головах. Десять лет пасу фришные сервачки и за всё это время проблем с версионностью шареных модулей не возникало ни разу. Хоть там те–же компоненты что и во всём опенсорсе. Всё дело в качественной системе портов и пакажей. А пока её нет — мы не настолько богаты временем, чтобы тратить его на временные решения без сильной на то необходимости. Либо «на века» — либо никак. ;–)

С твоей аргументацией по теме либко–ада согласен. Но не вижу смысла тратить свои личные ресурсы на то, что будет выброшено послезавтра. Предложение собирать программы самим в данной конкретной ситуации — оптимум.

Почему бы не

Почему бы не хранить в /some_app/lib линки на библиотеки различных версий /system/lib?

Да какая

Да какая разница, как оно будет устроено внутри? Хоть линками, хоть самими библиотеками. Лишь бы работало.

Будет занимать

Будет занимать меньше места

Повторюсь:

Повторюсь: место в наши дни — не проблема. А с тем, чтобы хранить все библиотеки в /system/lib, как раз есть проблема: часто у разных версий библиотек имена совпадают.

Но, ещё раз, какая разница, как это будет реализовано? Пусть на эту тему у создателей программ голова болит. Лишь бы программы работали и не глючили.

>Пусть на эту

>Пусть на эту тему у создателей программ голова болит.

то есть, не у «дистростроителей», выбирающих наполнение пакетного менеджера и дистроспецифичные патчи, а именно у авторов софта, который должен запускаться под всеми версиями «дистрибутивов»?

Тогда в гайку определённо нужно портировать 0install, http://0install.net/

Другими

Другими словами: проблема именно в поддержании целостности связей либка — приложение. Если третье приложение заменяет либку — то эта связь имеет шанс нарушиться. Грамотная система портов/пакажей эту проблему худо–бедно но решает. Но для этого такая система должна существовать для Гайки и должна использоваться подавляющим большинством пользователей. Вариант свалить используемые библиотеки в локальном «хранилище» ./lib — возможное решение, но разработчикам проще сказать, что «мы ждём пакажей» чем городить эти костыли. ;–)

разработчикам

разработчикам покамест прощё всё собирать в /usr/local, как это и происходит в ./configure, устанавливать /usr/local симлинками и не городить костыли :–))

Портирование &md

Портирование — это не перекомпиляция. Путей вида /usr/local на гайке не будет НИКОГДА — вопрос уже обсуждался. Для этого есть /boot/common — и конфигура с -–prefix успешно справляется с этой задачей. И это не костыли — это стандартное требование команды разработчиков. Это, кстати, не самое сложное требование для потенциального портировщика. Куда как сложнее будет заставить программы не гадитьфайлами настроек в хомяк а писать их в ~/config/settings. ;–)

А ссылку

А ссылку на портинг гайдлайнсы со стандартными требованиями можно в студию?
~/.config/appname — стандартные требования xdg :) нужно просто отобразить одно на другое Ж)

Как такового,

Как такового, подобного документа пока нет. Жёсткая позиция по поводу /usr/local была озвучена Акселем где–то в мейл–листе. Не знаю кто такой xdg, но седьмой версии вима на эти рекомендации наплевать. Подозреваю, что он не одинок в этом своем мнении.

xdg

xdg это http://standards.freedesktop.org/basedir-spec/basedir-spec–latest.html

Стандарт freedesktop.org на хранение конфигов в юниксовых приложениях.

нашел

нашел гайдлайнсы на http://ports.haiku–files.org. С первого взгляда порты кажутся похожими на гентушный portage.

И сразу вопрос — а сабжевый топик в этих портах присутствует? Можно ли поднять свой оверлей этих портов (например, захотел я локально что–то перенести и стал хакать последний чекаут из SVN. Да я же потом забодаюсь изменения сливать, если не буду делать коммит в SVN. Удобнее было бы иметь что–то вроде гентушных оверлеев и hg/git — пилить себе потихоньку свои пакеты в локальном оверлее, а как глюков станет мало, делать коммит в центральное дерево портов)

И насколько сложнее/более трудоёмко по поддержке три варианта:
1. самосбор из исходников
2. ports.haiku–files.org как «официальное» дерево портов
3. прикрутить гентушный paludis или portage, например.

???

PS. Ещё такой вопрос, а есть ли под Хайку драйвер рамдиска, вроде tmpfs в линуксе? У меня Gentoo с рамдиска на рамдиск собирает в два раза быстрее, чем на hdd. При сборке всего очень пригодилось бы.

Ах, да. Туда

Ах, да. Туда я забыл глянуть. ;–) Думаю, что вписку в тамошнюю команду никто не закрывал. ;–) Вас там примут с распростертыми объятиями. Я говорю абсолютно серъезно. Если есть время и желание — милости просим. По существу ваших вопросов вряд–ли отвечу — увы далек от этого. :–(

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

Про рам диск не помню. Под беосиной был точно, как здесь — не следил.

Кстати, jabber конференция этого сайта находится по адресу haiku–os@conference.jabber.ru. Если есть возможность, вопросы и желание — заходите.

Это всё можно

Это всё можно совместить. В Линуксе тоже есть не один–единственный пакетный менеджер.
Есть не только rpm, deb или .ebuild, но и 0install или nix, или Application bundles.
0install или application bundles как раз хорошо удовлетворяют твоим требованиям — один самодостаточный файл который выкачает остальные зависимости (0install) или в который завёрнуты все остальные зависимости (application bunldes — как папки–бандлы в MacOSX).

0install и Nix позволяют поставить одновременно разные версии библиотеки — потому что софт там ставится в хранилище, адресуемое по хеш–сумме от содержимого — фактически так же, как устроено «блоб–хранилище» в git (см. например Git# — они там пишут, как можно использовать git хранилище в качестве БД)

А сами зависимости разруливаются симлинками на объекты в хранилище, которые устанавливает пакетный менеджер.

Плюс, теоретически на это хорошо наслаивается тот же bittorrent и DHT таблицы — см. например, проект gittorrent, раздачу git репозитория через torrent (хотя и стандартного rsync во многих случаях хватит)

Со своей

Со своей стороны приветствую появление в Гайке Qt, gcc4, autotools, и прочего линукс–вея. Ещё хочется вот GTK 2.0 портировать, без иксов.
Хотя, все системные либы гайки + документация + bebook вместе взятые УСТАНОВЛЕННЫЕ занимают в два раза меньше места, чем то же Qt ЗАПАКОВАННОЕ.
Хоть Qt и есть толстый, жирный слон (а в пигвинуксе вот ядро за последние пару месяцев скакануло в .tar.bz2 с 35М до 60М) — но оно есть необходимое зло (да и дока там классная). Проще перенести софт используя готовые, устоявшиеся тулкиты и библиотеки, чем писать с нуля на таком прекрасном, замечательном велосипеде Be API + ALM для лейаутов + что–то такое для локализации.
Уже потом, когда выяснится, что большая часть этого софта — мусор (надеюсь, никто в здравом уме не станет портировать в гайку KDE4? :)) — можно будет и переписать стоящие единицы зёрен, отобранные из моря плевел :))

За что мы так

За что мы так любим БеОС? За то, например, что можно скачать программу, распаковать — и получить зачастую один исполняемый файл, который работает без инсталляци. Запускай — работает. А если и требуется инсталляция — не беда, она проводится в два клика мышкой.
А тот путь, что предлагаете вы, ведет к Линуксу. Вот, допустим, какой–нибудь линуксоид, наслышанный о прелестях БеОСи и Хайки, захочет мигрировать на Хайку, и увидит, что программы тут надо собирать самому, выкачивая по отдельности компоненты. Он посмотрит и скажет:
 — А чем это лучше Линукса? Все так же надо вручную собирать, да еще и запчасти по отдельности скачивать. А у меня в Линуксе хоть менеджер пакетов есть, да и программ до чёрта, и драйверов к куче оборудования, и, наконец, мощная поддержка в разных сообществах. А тут что? Не–а, не буду пока что мигировать.
Да, я услышал ваши слова о том, что пока что активно развивают Хайку лишь пять человек, и пока не станет больше, нет смысла бла-бла–бла. А как же их может стать больше, если вы предлагаете «покамест» вот такой путь развития, ну а когда Хайку станет большой, тогда и будем делать нормальные инсталляторы программ, работающие под любой версией? Так любой человек посмотрит на это и скажет:
 — Вот когда сделают толком, тогда и присоединюсь.
И в самом деле, зачем менять шило на мыло, если при этом шило острое, а мыло не мылится?
Предугадываю ваш ответ: мол, заинтересованный человек не испугается таких трудностей, а абы–кого нам не надо, пусть сидят под своей виндой и т.п.
Но ведь если не привлечь разработчиков уже сейчас, а предлагать нечто вроде «Давайте мы пока что будем вот так делать, сложно и неудобно, зато когда нас станет миллион, мы перейдем к нормальным инсталляторам и менеджерам пакетов», — то, боюсь, Хайку из альфы еще и вторые восемь лет не вылезет.

Что касается портирования программ, то это всяко хуже, чем создание нативных приложений. Лучше, конечно, чем ничего, но хуже нормального пути развития.
Портировали Иксы, портировали Qt, затем еще какой–нибудь Гном портируем. И что в итоге получится? Для запуска этой программы в 50 Кб мне нужен Х11 в десяток мегабайт, для вот этой — Qt еще в полста метров (условно), для этой — еще какой–нибудь амижный порт. В итоге мы прийдем к какому–то очередному линукс–пути: а зачем искать нативные проги, если под Wine и так все работает?
Имеем в Хайке портированные приложения, которые считаются лучше, чем нативные, но при этом убогие и недоработанные. Примеры? Да вы и сам знаете: VLC, Mozilla, например. А теперь с портированием Qt и программ ейных еще новую порцию косячных программ получим. И так все будем портировать, портировать, и в итоге через несколько лет в системе будут одни портированные приложения — а зачем тогда писать нативные? Зачем привлекать разработчиков?
------------------------------–
BeOS 5.0.5 BONE mini version, Celeron 500 MHz, RAM 320 Mb, GeForce 5200 128 Mb

За что мы так

За что мы так любим БеОС? За то, например, что можно скачать программу, распаковать — и получить зачастую один исполняемый файл, который работает без инсталляци. Запускай — работает. А если и требуется инсталляция — не беда, она проводится в два клика мышкой.

Ты просто пребываешь в блаженно неведении. Проблемы как правило начинаются уже на этапе удаления этой программы. Поскольку ЛЮБАЯ нативная беосная прога регистрирует МИМЕ типы для документов с которыми она работает. И к твоему сведению, простое удаление папки с программой не удалит их автоматически из базы. Посему появляются програмки типа Revenge Mutant MIME Types — для любителей сухотрочки на чистоту… Ешё веселее мне наблпюдать как будет удаляться, например, видеодрайвер установленный так любимым во времена оные дроп-ин–ом на линки системных дир. Беосный подход казался приемлемым лишь потому, что программ было мало, и были они до смешного компактными (читай примитивными). Дальнейшее развитие неизбежно привело–бы к кризису такого подхода. Не могло не привести — ибо бардак. Беосина просто не успела вылезть из песочницы.

Специально для тебя, как редкого гостя, повторяю: ГРАМОТНЫЙ МЕНЕДЖЕР ПАКЕТОВ ОТРАБОТАЕТ ВЕСЬ ЦИКЛ ОБСЛУЖИВАНИЯ ПРИЛОЖЕНИЯ ОТ УСТАНОВКИ, АКТУАЛИЗАЦИИ (ОБНОВЛЕНИЯ) И УДАЛЕНИЯ. В. АВТОМАТИЧЕСКОМ РЕЖИМЕ! Всё что требуется от пользователя — изъявить желание: установить, обновить либо удалить программу. Всё! Такой сервис убогому Software Валету и не снился, до него ему как до Луны вприсядку.

А тот путь, что предлагаете вы, ведет к Линуксу.

Послушай, ты ведь не домохозяйка, а технически грамотный человек. Уважай собеседников — выражайся четко и ясно — это ведет к хаосу и беспорядку. А Линукс — это операционная система с абсолютно иной архитектурой философией и идеологией. Гайка Линуксом никогда не станет.

Вот, допустим, какой–нибудь линуксоид, наслышанный о прелестях БеОСи и Хайки, захочет мигрировать на Хайку, и увидит, что программы тут надо собирать самому, выкачивая по отдельности компоненты.

Да, придурок — увидит только это, да и уйдёт. И пускай идет — зачем нам придурки, для которых декор важнее многопоточности? Умный же человек увидит гораздо большее — Альтернативу. И его заинтересованность наличием общеизвестных программ будет только стимулирована.

Имеем в Хайке портированные приложения, которые считаются лучше, чем нативные, но при этом убогие и недоработанные. Примеры? Да вы и сам знаете: VLC, Mozilla, например.

Аргумент ведь совсем не в ту сторону что тебе кажется. Задумайся — даже порт, уже готовую программу довести некому! Стоит дом, стены, крыша — стекла в окнах, отопление подведено, жить можно — но вот стены штукатурить рук не хватает да проводку грамотнее развести времени нет. А ты предлагаешь в лес за кругляком ехать — новый сруб ставить — покрасивее мол и правильнее чем этот силикат. В реальной жизни бы тебя в тот лес отвезли да медведям скормили за такие идейки. ;–)

Да, я услышал ваши слова о том, что пока что активно развивают Хайку лишь пять человек, и пока не станет больше, нет смысла бла–бла–бла. А как же их может стать больше, если вы предлагаете «покамест» вот такой путь развития, ну а когда Хайку станет большой, тогда и будем делать нормальные инсталляторы программ, работающие под любой версией?

Утопающий и соломинке рад, потому как истинно–правильного спасательного круга из пробки он может и не дождаться. Дальше продолжать? Но предупреждаю, там будет много мата и объяснений на конкретных физиологических примерах о месте Гайки в этой жизни, её текущей востребованности и моего предвзятого мнения о парнях, любящих повещать о чистоте идей.

Подумай над тем фактом, что без портов гайка бы до сих пор и компилятора не имела–бы.

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

Поосторожнее с речью от первого лица множественного лица, ибо я пока не слышал о программных продуктах для гайки под твоим авторством пусть даже и портированных. вы (т.е. ты) _не_ портировали — портировали Евгений с Герасимом — и право говорить _мы_ в этом контексте есть у них. И QT тебе насильно на систему никто не ставит — не хочешь не пользуйся. А что «нормальных» програм не будет — так их так и так не будет, что с QT, что без QT. Ибо гайки пока даже и не видно из–под плинтуса статистической погрешности.

Зачем привлекать разработчиков?

Впрочем никто тебе не мешает привлечь, нанять, ЛИЧНО профинансировать команду профессиональных разработчиков, оплатить их обучение, пару десятков человеко–лет работы и мы будем с удовольствием покупать твои программы, буде они окажутся нам нужными и стоящими своей цены. Ты готов рискнуть своими средствами? Если нет — так чего–же ты учишь других как им поступать? Бревно из глаза вынь — не уподобляйся красноглазым GPL–законникам и адептам Секты Пингвина, да? :–)

И в пятый раз повторюсь, Я РАЗДЕЛЯЮ ВАШЕ БЕСПОКОЙСТВО ПО ПОВОДУ БАРДАКА. В. ПОРТИРОВАННОМ СОФТЕ. Но! Вопрос стоит именно в создании грамотного менеджера пакетов. И я также предпочитаю устанавливать, обновлять и удалять програмные пакеты одним движением пальца — без уделения внимания происходящим за кулисами процессам.

А, может, ну его

А, может, ну его нафиг — ждать буржуйского дядю — и сами напишем менеджер пакетов для Гайки? Сформулируем требования, напишем дизайн, разбросаем классы по разработчикам, и за годик–полтора напишем приличную софтину. А то локализовывать да тестировать все горазды.

А почему gcc 2?

А почему gcc 2? В Гайке есть же gcc 4.3.4, выбирается через setgcc.
Я вот попытался им в R1/alpha1 r31xxx (с чем–то, не помню — та, что альфа вышла) собрать — и уткнулся в glib. Glib захотел gettext — gettext собрался нормально, конфигурялся через ./configure --build=i586-pc–haiku или --build=i586-pc–beos. А потом glib захотел libresolv с res_query в процессе своей ./configure. Грепается libbind.so (он же cимлинк на libnetwork.so), вроде есть такой символ. Но конфигура не находит и библиотеку не определяет. Возможно, потому что пытается собрать и -lresolv и -lbind, а нужно только с -lbind.
Glib сейчас с nightly сборками как, нормально собирается?
>Любой билд Haiku (кроме чистого GCC4, я использовал R34190 2/4)

может, это та альфа1/R1 плохая сборка? собирал заодно DMD, наткнулся на глюки в линкере.

А вообще народ, может стоит прикрутить emerge или paludis из Генты и собирать новый профиль в Генте, сделать свой оверлей с патчами, портировать основной профиль портеджей? :^)
Хотя питон, емёрдж и гента это тот ещё велосипед, лучше уж сразу брать paludis и какой–то exherbo :)

А почему

А почему gcc 2?

Требование совместимости с BeOS R5. После R1 оная будет похерена.

При попытке

При попытке сконфигурировать mc возникла такая проблема: ругается на то, что не находит glib–config. Сам glib по ссылке выше у меня установлен, но у glib 2 этого glib–config нет вообще, а ./configure его просит. Подскажите, как решить эту проблему?

Это он так

Это он так на отсутствие pkg–config вроде руагется. Он установлен?

Спасибо

Спасибо за совет, проблема была в pkg–config. Откомпилировать mc удалось, но при запуске выдает ошибку — Error opening terminal: xterm Не подскажете, в чем сейчас проблема?

попробуй

попробуй поставить в ~/.profile строчку

export TERM=xterm–color

заодно и цвет будет. А команда env что показывает в переменно среды TERM?

TERM равнялось

TERM равнялось xterm, после добавления в ~/.profile export TERM=xterm–color и перезагрузки изменилось на xterm–color, но при попытке запуска mc теперь выскакивает ошибка error opening terminal: xterm–color.
Система: R1A2, в vmware установлен обычный образ для установки с CD. Может быть проблема в том, что я не ставил отдельно gettext и libiconv, но они, похоже, уже предустановлены в дистре.

Установил

Установил депендансы из бинарников, прикрепленных в статье, и пересобрал — та же самая ошибка вылетает при попытке запуска mc.

Проблема

Проблема с ncurses
Проверь, на месте ли каталог /boot/common/share/terminfo и его содержимое

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Allowed HTML tags: <a> <em> <i> <img> <strong> <b> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Подробнее о форматировании

CAPTCHA
Введите перечисленные символы, чтобы мы убедились, что вы не робот. Не требуется для зарегистрированных пользователей.
F
p
g
D
u
Q
Enter the code without spaces and pay attention to upper/lower case.