The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Дискуссия о возможности включения QtWebEngine в дистрибутивы Linux и другие ОС

23.04.2015 02:18

Начиная с версии 5.4, в составе широко распространённого тулкита Qt поставляется QtWebEngine — встраиваемый Web-компонент на основе Blink/Chromium. Изначально планировалось, что в будущем QtWebEngine заменит основанный на Webkit компонент QtWebkit, так как его поддержка в Qt, со слов разработчиков Qt, требует в разы меньших усилий. Однако мейнтейнеры ряда основных дистрибутивов Linux (Debian/Ubuntu и Fedora, как минимум), а также других ОС, пришли к выводу, что использование кодовой базы Chromium приводит к слишком большим проблемам в сопровождении:

  • Chromium содержит вшитый FFmpeg вместо использования, например, GStreamer. Как результат, невозможно добавить, удалить или заменить кодеки способом иным, нежели перекомпиляция Chromium.
  • Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86.
  • Сборка Chromium с использованием внешних компонентов вместо поставляемых в комплекте с исходными текстами изначально затруднена и требует большой работы со стороны мейнтейнеров, зачастую повторяющейся при каждом обновлении Chromium (а обновления выходят довольно часто).
  • Сборка Chromium отнимает довольно много ресурсов; сборка QtWebEngine означает ещё одну сборку Chromium, причём с использованием альтернативного сборочного инструментария (qmake), что означает ещё больше усилий, чем требуется на оригинальный Chromium - и это получается лишь один из компонентов Qt.
  • Мультипроцессная архитектура Chromium автоматически наследуется в QtWebEngine, усложняя контроль над работающими приложениями.

В связи с этим возникли такие вопросы как:

  • Насколько оправдано применение QtWebkit/QtWebEngine в KDE и других приложениях;
  • Какие существуют альтернативы (например, QTextView имеет базовые возможности по интерпретации HTML).

Пока что выработать универсальное решение не удаётся. Возможно, привлечение большего числа специалистов поможет найти таковое (список рассылки kde-core-devel модерируется, поэтому угрозы замусоривания обсуждения нет).

  1. Главная ссылка к новости (http://marc.info/?l=kde-core-d...)
  2. OpenNews: Релиз фреймворка Qt 5.4 и среды разработки Qt Creator 3.3.0
  3. OpenNews: Qt переходит с WebKit на браузерный движок Blink и технологии Chromium
  4. OpenNews: Первый предварительный выпуск Qt WebEngine, переведённый на браузерный движок Blink
Автор новости: Вадим Жуков
Тип: Тема для размышления
Ключевые слова: qt, chromium
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, annualslayer (ok), 09:18, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    пусть netsurf допиливают :)
     
     
  • 2.3, Аноним (-), 09:29, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну не обязательно NetSurf
    Можно перефразировать так: нужен высококачественный рендер HTML-а (с поддержкой всех версий) с гибкими возможностями доступа к DOM и стилям.
    JS не нужен для самого приложения.
    Решение данной задачи позволит создать "новый подход" к построению интерфейсов пользователя. Но этого не будет - потому что разрабатывать решение без гвоздей никто не станет.
     
     
  • 3.24, kravich (ok), 11:59, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +12 +/
    >нужен высококачественный рендер HTML

    Gecko?

     
  • 3.25, Аноним (-), 12:04, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Ну не обязательно NetSurf
    > Можно перефразировать так: нужен высококачественный рендер HTML-а (с поддержкой всех версий)
    > с гибкими возможностями доступа к DOM и стилям.
    > JS не нужен для самого приложения.
    > Решение данной задачи позволит создать "новый подход" к построению интерфейсов пользователя.
    > Но этого не будет - потому что разрабатывать решение без гвоздей
    > никто не станет.

    Более того, в Qt уже есть и вполне работоспособна поддержка JS через тот же JavaScriptCore. QtWebEngine (пока что), если смотреть исходники Qt 5.4, впилен весьма грубо и практически не интегрирован с остальными подсистемами Qt - в отличие от того, как расползся QtWebKit.

    Всё упирается в то, что пилить свой полноценный Web-движок разработчики Qt не в состоянии (и здесь их не за что винить, это действительно большой труд), а чужие разработки, все как одна, представляют собой вещи в себе, требующие подчинения собственным правилам. В Qt хотят иметь интегрированный веб-движок, а всё, что сейчас есть полноценное и актуально развивающееся (Blink, Gecko...), навязывает свои правила. Какая уж тут интеграция.

    Если вот так посмотреть, то единственный актуальный браузер, движок которого интегрируется с ОС, а не пытается всё тянуть на себе, это Internet Explorer. :-\
    (для озабоченных: это всего лишь мрачная шутка)

     
     
  • 4.29, Анонимомус (?), 12:39, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Webkit не умирал, единственный момент, возможно в Qt использовалась не 2-я его версия.
     
     
  • 5.47, Аноним (-), 06:50, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Его обновление каждый раз тоже дорогого стоит, со слов Qt-шников - и я им, почем... текст свёрнут, показать
     

  • 1.2, Аноним (-), 09:19, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86.

    На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут проблемы

     
     
  • 2.11, AlexYeCu_not_logged (?), 09:53, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут проблемы

    Какие? На arm вон вполне работает, производительность, правда, не замерял.

     
  • 2.23, Аноним (-), 11:55, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86.
    > На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут
    > проблемы

    Насколько знаю, Chromium в обязательном порядке требует JIT. Который в случае V8, если верить обсуждаемой дискусии (бр-р-р), работоспособен только на i386/amd64.

     
     
  • 3.37, Аноним (-), 15:02, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > если верить обсуждаемой дискусии (бр-р-р), работоспособен только на i386/amd64.

    Вот те раз. А как же у меня хромиум на армовской платке работал?

     
     
  • 4.46, Аноним (-), 06:34, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Значит, у меня (и кого-то в дискуссии... придётся опять в неё лезть) сведения неверные. Спасибо за уточнение. :)
     

  • 1.4, анн (?), 09:32, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    заголовок к содержанию не имеет абсолютно никакого отношение.
     
     
  • 2.26, Аноним (-), 12:05, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > заголовок к содержанию не имеет абсолютно никакого отношение.

    Почему?

     

  • 1.7, arzeth (ok), 09:43, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Сборка Chromium отнимает довольно много ресурсов;

    Разве у собиральщиков не по >=12 ГБ оперативки с Core i5/Xeon?
    > Chromium содержит вшитый FFmpeg

    Есть же флаг -Duse_system_ffmpeg=0 для использования системного.
    В 2012 году сделали, чтобы нормально с ним собиралось: https://code.google.com/p/chromium/issues/detail?id=118986
    А в 2014 дебианщик патчи предложил, чтобы опять собиралось: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763632

     
     
  • 2.22, Аноним (-), 11:54, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Даже если заставить таки собираться с системной версией что потребует периодиче... текст свёрнут, показать
     
     
  • 3.59, freehck (ok), 01:17, 27/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Даже если заставить таки собираться с системной версией (что потребует периодического допиливания кода chromium из-за разницы API FFmpeg разных версий)

    Не говоря уже о том, что в Debian уже 2 релиза нету ffmpeg, а вместо него libav.

     
     
  • 4.61, wWolf (?), 13:30, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не правда ваша, в свежерелизнутой 8-ке (Jessie) исправили это недоразумение мантейнера-фанатика от libav, и теперь ffmpeg этот действительно ffmpeg, ну и libav тоже пока выкидывать не стали. А для тех кто был на тестинге это случилось еще год-полтора назад.
     
     
  • 5.62, Andrey Mitrofanov (?), 15:59, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Не правда ваша, в свежерелизнутой 8-ке (Jessie) исправили это недоразумение мантейнера-фанатика
    > от libav, и теперь ffmpeg этот действительно ffmpeg, ну и libav

    всё абсолютно не так.

    > тоже пока выкидывать не стали. А для тех кто был на
    > тестинге это случилось еще год-полтора назад.

    --А что, отец, тестинги в городе есть?
    --Кому и unstable - тестинХ.

    В sid-е - есть, а в jessie b stretch-е https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#msg159 *нет*. //На p.d.o сам как-нибудь.

    В jessie они убрали "transitional package" ffmpeg, собранный из src:libav.

     
     
  • 6.63, Andrey Mitrofanov (?), 16:04, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> тоже пока выкидывать не стали. А для тех кто был на
    >> тестинге это случилось еще год-полтора назад.
    > --А что, отец, тестинги в городе есть?
    > --Кому и unstable - тестинХ.
    > В sid-е - есть, а в jessie b stretch-е https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#msg159
    > *нет*.

    Хотя, да. Если "давно", то, возможно, до заморозки и прореживания jessie это было по-другому.

    ++Что ж Вы, свои тестинги не чистите, что ли?

    > //На p.d.o сам как-нибудь.

     

  • 1.8, nc (ok), 09:47, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пускай выкупят у оперы исходники Presto и включат в Qt (а заодно и исходники откроют)!
     
     
  • 2.9, Аноним (-), 09:50, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Отличная идея, денег подкинешь?
     
     
  • 3.16, Аноним (-), 10:50, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Краудсорсинг
     
  • 3.33, nc (ok), 13:19, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    При чем тут деньги? Если продукт хороший, то компания, открывающая его, получает бесплатную разработку и поддержку продукта сторонними разработчиками в обмен на предоставление исходников всему миру.
     
     
  • 4.36, Аноним (-), 13:48, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Учитывая, что Opera забила на Presto и переехала на Chromium, им эта бесплатная разработка и поддержка не нужна.
     

  • 1.12, AKR (ok), 10:01, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Тут (https://github.com/OtterBrowser/otter-browser/wiki/QtWebEngine-Wishlist) Emdek ведёт вики по нехватающим в QtWebEngine вещам
    Источник, и связная тема тут: http://forum.ru-board.com/topic.cgi?forum=5&topic=46573&start=186&limit=1&m=1
     
  • 1.15, Собака (?), 10:25, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    XULRunner же!
     
     
  • 2.18, Аноним (-), 10:56, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Уже было примерно 5 попыток портирования XUL на Qt (Firefox на Qt). Пока неуспешно. Получается, что этот XUL не отличается переносимостью.
     
  • 2.54, Slowpoke (?), 16:18, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ЗулРаннер не нужно, хватило бы движка для рендера страниц - Геко(или что там у Мозиллы свежее)
     

  • 1.17, Михрютка (ok), 10:51, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    некоторые цитаты прекрасны

    некто@kde.org:
    IMHO the duty of a distro is providing software to their users to use, if the
    rules of the distro make providing software hard/impossible they need to be
    updated or these distros need to understand they will lose users to more
    flexible distros.

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

    потому что кластерфак, который они устроили с четвертой веткой, судя по всему, только крепчает:
    >I know that kdepim seems to depend on it (QtWebEngine) now.

    над кдешником, предложившим "а чо-чо, если вам так тяжело <s>собирать</s> мейнтейнить наши кедочки, просто TRUST US и берите нашу сборку", откровенно глумятся:

    > Just state that there's no such long maintaince time for that package o> r just
    > install the newer version of Qt. And yes again that probably goes again> st your
    > rules, but it's your rules, so you can just improve them for everyone's>
    > benefit :)

    Let's just try to follow that thru.

    A new QtWebEngine pulls in a new Qt. The newer Qt breaks somehow Plasma,
    because relying on internals. Then a newer Plasma is pulled in. THat
    requires a newer KDE Frameworks, and a newer Wayland and a newer Mesa.
    Those two components requires a newer kernel. The newer KDE frameworks
    also has a couple of extra requirements.  Some of those extra
    requirements happens to break parts of the Gnome stack. So a update of
    that is needed too. That requires a newer systemd, that discovers issues
    with apache. The newest apache has a changed plugin api that requires
    changes to all the apache extensions. Including php, ruby and python.

    You can likely continue the story yourself from here.

    Unfortunately, I haven't really used my imagination here.

    "чума на оба ваших чума!"(с)

     
     
  • 2.27, Аноним (-), 12:08, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Что самое смешное, уже известно, что если Debian откажет... текст свёрнут, показать
     
     
  • 3.30, Михрютка (ok), 12:40, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Что самое смешное, уже известно, что если Debian откажется мейнтейнить (то есть,
    > в том числе, паковать) QtWebEngine, то Ubuntu сделает то же самое.
    > А поскольку у Ubuntu и Kubuntu общая пакетная база... ;)

    my point exactly

    > Хотя нет, самое смешное, это то, для чего QtWebEngine используется в KDE
    > PIM - есть там же, в дискуссии. :)

    The only part so far, that depends on QtWebEngine in kdepim is
    KSieveUi::SieveEditorWebView

    ШТОА

    а хотя чего я удивляюсь, после мускля-то.

    "тут уже не исправишь ничего господь жги"


     
     
  • 4.43, GotF (ok), 19:02, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > The only part so far, that depends on QtWebEngine in kdepim is

    KSieveUi::SieveEditorWebView

    Чистая победа.

     

  • 1.19, Аноним (-), 11:45, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вообще с браузерами беда ... Кривые они все...
     
     
  • 2.38, Аноним (-), 15:09, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вообще с браузерами беда ... Кривые они все...

    В данном случае злобство в том что ЛИБА которая будет рендеря пагу ФОРКАТЬ ПРОЦЕССЫ, городить песочницы и делать over 9000 незапрошенных в общем то действий - это ЖЕСТЬ.

     

  • 1.28, Аноним (-), 12:26, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Да включайте в LSB - вместе с Dbus - а не договаривайтесь с каждым комьюнити отдельно. Только пульсу не берите, пожалуйста, в стандарт, описывающий либы, которые обязаны быть в любом линуксе.
     
     
  • 2.31, Andrey Mitrofanov (?), 12:53, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Да включайте в LSB - вместе с Dbus - а не договаривайтесь
    > с каждым комьюнити отдельно. Только пульсу не берите,

    В zewstemdie же. Он уже "в каждой затычке". А LSW не молодёжен. </>

     

  • 1.32, правдоруб (?), 13:13, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >в составе широко распространённого тулкита Qt поставляется QtWebEngine

    Ну и комбайн... Кто-нибудь уже предлагал переписать Emacs на Qt?

     
     
  • 2.34, Аноним (-), 13:26, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А что, было бы интересно.
     
     
  • 3.35, Andrey Mitrofanov (?), 13:47, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, было бы интересно.

    $ konsole -e emacs -nw_

     
  • 2.60, freehck (ok), 01:24, 27/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>в составе широко распространённого тулкита Qt поставляется QtWebEngine
    > Ну и комбайн... Кто-нибудь уже предлагал переписать Emacs на Qt?

    А почему не Qt на Elisp? А то я чувствую, что мсьё знает толк в извращениях.

     

  • 1.39, Aceler (ok), 18:27, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Гм. Был KHTML — делали на KHTML. Потом пришёл QtWebKit — форк KHTML, начали переезжать на QtWebKit. Теперь вот QtWebKit собираются заменить на QtWebEngine.

    Может, им просто откопать обратно KHTML?

     
     
  • 2.41, Andrey Mitrofanov (?), 18:51, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Может, им просто откопать обратно KHTML?

    1. Им нужен веб-движок - для понтоваться перед пацанами.
    2. Ментеёнить или девелопить они его не могут.

    Вывод: тащут всё, что недевелопят модные ребята с раёна с синдромом раздражённого релиза. Догонялки, навар, бульон. Всё так и было задумано. Теми модными ребятми.

     
  • 2.48, Аноним (-), 07:03, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Гм. Был KHTML — делали на KHTML. Потом пришёл QtWebKit — форк
    > KHTML, начали переезжать на QtWebKit. Теперь вот QtWebKit собираются заменить на
    > QtWebEngine.
    > Может, им просто откопать обратно KHTML?

    KHTML делали не в Qt. И, судя по проскакивающим заявлениям, от KHTML в KDE планируют отказываться, его банально практически никто не поддерживает.

     
     
  • 3.49, nib (?), 10:46, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > KHTML делали не в Qt

    Lars Knoll, Simon Hausmann.. ага;) бтв от khtml планируют отказаться уже много лет

     
     
  • 4.50, Аноним (-), 11:03, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Так они, вроде, тогда были лишь KDE-разработчиками, не?
     
     
  • 5.52, nib (?), 11:48, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Судя по их linkedin'у lars уже в троллтехе работал, simon да только в kde участвовал
     
  • 4.51, Аноним (-), 11:06, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > бтв от khtml планируют отказаться уже много лет

    BTW, когда патчил KDE под OpenBSD :) , я не стал заморачиваться на тему "почему падает KJS" и сразу поставил kwebkitpart по умолчанию - жёсткая run-time зависимость и приоритет выше KHTML. Ни одной жалобы. Так что кое-где _уже_ отказались от KHTML. ;)

     

  • 1.40, Аноним (-), 18:41, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пусть лучше помогут Servo допилить. За одно и его используют)
     
     
  • 2.42, Andrey Mitrofanov (?), 18:53, 23/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пусть лучше помогут Servo допилить. За одно и его используют)

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

     

  • 1.44, Аноним (-), 22:55, 23/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отставьте как есть. Зато в нем и флеш и html5 работают, в отличии от.
     
  • 1.45, nexfwall (ok), 00:39, 24/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Тут выбора всего 2. Либо перепиливать chromium как надо, чтобы к его пересборке не было никаких претензий. Либо посылать QtWebEngine куда подальше.

    > Мультипроцессная архитектура Chromium автоматически наследуется в QtWebEngine, усложняя контроль над работающими приложениями.

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

     
  • 1.53, Slowpoke (?), 16:13, 24/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему бы не выкинуть Webkit и взамен использовать SpiderMonkey|GreaseMonkey от Мозиллы?
     
     
  • 2.55, Andrey Mitrofanov (?), 17:35, 24/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А почему бы не выкинуть Webkit и взамен использовать SpiderMonkey|GreaseMonkey от  Мозиллы?

    Может быть потому, что это не web-движки?

    ""SpiderMonkey is the code name for the first-ever JavaScript engine, written by Brendan Eich at Netscape Communications

    ""Greasemonkey — расширение Mozilla Firefox, позволяющее добавить на любую страницу пользовательский JavaSc

     
     
  • 3.56, DFX (ok), 05:22, 25/04/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Но ведь Вы, Товарищ Язвитель, поняли что речь автора выше о Gecko. Ну так, в чём проблема с ним ?
     

  • 1.57, бедный буратино (ok), 15:43, 25/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    от вебкита до вебкита
    сто километров езды
    но дистрибу дебиана
    это дело до ... звезды
     
     
  • 2.58, Andrey Mitrofanov (?), 09:59, 26/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > но дистрибу дебиана
    > это дело до ... звезды

    Мимо тёщина забора я без шутки не хожу,
    то s-d туда засуну, то бородатого ветерана покажу.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру