LINUX.ORG.RU

Форум (без talks)

Использование VRAM при взаимодействии с MCP

 , ,

Имею llama.cpp, https://huggingface.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF

# llama-server --host 0.0.0.0 --port 8000 -m ./Qwen3-Coder-30B-A3B-Instruct-IQ4_NL.gguf --jinja --temp 0.7 --min-p 0.0 --top-p 0.80 --top-k 20 --repeat-penalty 1.05 -fa off -lm mlock --n-cpu-moe 99 -c 100000 --cache-type-k q8_0

Запускается, занимает 14637M VRAM.

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

Второй вариант: беру https://github.com/Luxshan2000/fastmcp-file-server подключаю к llama.cpp серверу, делаю запрос «в директории $$$ проекта прочитай файлы [список относительных путей до всех нужных к переводу файлов] выполни перевод всех китайских сообщений на английский язык.»
Оно доходит до запроса MCP на чтение файла и с этого момента начинает медленно и уверенно «выедать» VRAM.
Далее оно или упадёт в OOM или закончит, но VRAM не высвободит.

Объясните почему так во втором варианте, можно ли его как-то заставить хотябы высвобождать VRAM по завершению запроса?

Flotsky
()

А мой опрос про оперативку по какой причине удалили? (Его не удалили!)

 , , , ,

UDP: Произошла магия, он есть, но его нет!

Мне не жалко, фиг с ним, просто интересно :) Неужели было всё так плохо? Видимо это сделали уже давно, в «Последние удаленные неподтверждённые» ничего нет

LINUX-ORG-RU
()

Коммодитизация ИИ уже?

 

Интеллект базовых моделей быстро превращается в «электричество» — дешёвый товар с низкой добавленной стоимостью (commodity). Когда разница между закрытой моделью за $20/1M токенов и открытой моделью за $0.10/1M токенов становится минимальной никакие меры по закрытию и ограничению доступа к моделям не работают.

Ваша оценка – комодизация уже произошла (война резко упавших цен доступа) или это все «временные трудности»?

psv1967
()

Выбор init-системы для десктопного LFS: systemd, OpenRC, runit или dinit?

 , , ,

Всем привет! Собираю свой дистрибутив на базе LFS. Система рассчитана на повседневный десктоп для ПК средних характеристик и будет полностью оптимизирована (включая общую производительность, игры и проприетарные драйверы NVIDIA). Ультра-минимализм и экономия каждого байта ОЗУ не требуется, но и лишний оверинжиниринг не нужен. Встал вопрос с выбором инит-системы и сервисного менеджера. В LFS-буке основные варианты — systemd и SysVinit, но смотрю и на альтернативы (OpenRC, runit, dinit, s6). Посоветуйте, что лучше выбрать под такие задачи?

Перемещено hobbit из general

BashDev
()

Посоветуйте библиотеку soap

 , ,

Привет форум, подскажите SOAP библиотеку кроссплатформенную желательно для SOAP C++

doomer
()

«Cгенерированный ИИ контент не является объектом авторского права"TM — как это угрожать может GPL и „публик домайн“ софту?

 

Это важнейший юридический парадокс эпохи ИИ, который сейчас активно разбирают юристы в сфере Open Source (включая Software Freedom Law Center и Free Software Foundation). Угроза для GPL (Copyleft) и Public Domain здесь фундаментальная, и она заключается в том, как устроена сама юридическая механика лицензий. Корень проблемы: GPL держится ИСКЛЮЧИТЕЛЬНО на авторском праве Лицензия GPL — это не отдельный закон. Это договор, вытекающий из авторского права (Copyright). Логика GPL проста: «Я владею авторским правом на этот код. Я разрешаю вам его использовать, НО ТОЛЬКО если вы соблюдаете мое условие — открываете свой производный код под той же лицензией GPL». Если код, созданный ИИ, не имеет авторского права (то есть признается не имеющим человеческого авторства и автоматически падающим в Public Domain), вся конструкция GPL рушится. Вот 3 главных сценария, как это угрожает Open Source:

  1. «Отмывание» GPL-кода через ИИ (GPL Laundering) Представьте, что проприетарная корпорация хочет использовать мощный алгоритм, написанный под жесткой лицензией AGPLv3 / GPLv3 (которая запрещает закрывать код). Инженеры компании берут GPL-код и скармливают его нейросети с промптом: «Перепиши этот алгоритм на Rust/C++, измени названия переменных и структуру классов». ИИ выдает рабочий переписанный модуль. Юристы компании заявляют: «Этот код сгенерирован нейросетью. На него нет авторских прав, а значит, на него НЕ РАСПРОСТРАНЯЕТСЯ лицензия GPL исходника. Мы вставляем его в наш закрытый коммерческий продукт». Итог: GPL-лицензия превращается в решето. Любой защищенный код можно «отмыть» через нейросеть и закрыть в проприетарном софте.
  2. Потеря возможности защищать свой софт в суде Представьте, что вы — автор open-source проекта. Вы написали 10 000 строк кода, активнее всего используя терминальные ассистенты (OpenCode, Cursor, Copilot). Если IT-гигант заберет ваш код, нарушит GPL и встроит его в свой коммерческий сервис, вы пойдете в суд. Но в суде юристы гиганта скажут: «Уважаемый суд, 70% кода истца сгенерировано ИИ (что видно по промптам и стилю). На этот код у истца НЕТ авторского права. А раз нет авторского права, истец не имел права налагать на нас условия GPL. Требование открыть наш софт недействительно». Вы не сможете защитить свой софт, потому что закон не признает вас автором того, что напечатал ИИ.
  3. Смерть концепции Copyleft и победа Permissive/Public Domain Отсутствие авторских прав на ИИ-код фактически убивает концепцию Copyleft (GPL) и принудительно переводит весь мир разработки на рельсы Public Domain / MIT. Copyleft (GPL) требует: «Взял мое — отдай свое». Public Domain / Permissive (MIT) говорит: «Бери кто хочет, делай что хочешь, никто никому ничего не обязан». Если ИИ генерирует код без авторских прав, он автоматически становится Public Domain. Его может забрать любой коммерческий гигант, дописать пару строк и продавать как закрытый сервис. Авторы открытого софта теряют рычаг, который 30 лет заставлял корпорации делиться своими доработками с сообществом. Как юристы пытаются заделать эту брешь? Сейчас в международных судах формируются два защитных барьера: Доктрина «Существенного человеческого вклада» (Substantial Human Contribution): Юристы пытаются доказать, что если человек проектировал архитектуру, составлял промпты, правит и интегрирует код, то авторское право сохраняется на ансамбль и результат работы, а ИИ был лишь «умной кистью» (как Photoshop). Иски о нарушении лицензий при обучении (GitHub Copilot Lawsuit): Разработчики доказывают, что если ИИ обучался на GPL-коде и генерирует его фрагменты без сохранения текста лицензии GPL и авторских указаний (attribution), то сам провайдер ИИ нарушает GPL еще на этапе выдачи ответа.
psv1967
()

Новорег dobro спамит клоунами

 

$subj

@dobro, тебя забанят, а ты не флуди

unclestephen
()

Пожалуйста, возьмите с собой собственную материнскую плату, радиатор и TF-карту.

 , , , ,

Сабдж

Как водится, китайцы все врут, и это просто корпус для Raspberry Pi, Rock5C и плат Оrange Pi аналогичного размера за 11 тыс.р. с 4'' монитором и клавой (без русских буквов), но, прикольно. Хэндхелд этакой.

… и стою, я, значит, с ASUS ROG Strix, радиатором отопления и микроSD-шкой, и на лыжах…

tiinn
()

Компьютер долго включается

 

При включении или перезагрузке иногда машина надолго задумывается. Может несколько минут стоять с чёрным монитором, прежде чем появится меню GRUB. Если дошло до загрузки — какое-то время загружается без проблем.

Материнская плата: Micro-Star International PRO B850-P WIFI (MS-7E56)
Процессор: AMD Ryzen 9 9950X3D 16-Core
Видео: GeForce RTX 5090
Жёсткий диск: Seagate ST20000NM007D-3D

Вывод lshw: https://pastebin.com/fhcpTT1A

В чём может быть проблема? Куда копать?

Промежуточный итог:

Обновил BIOS до 2A92 от 25.06.2026 (до того был 2A75 от 10.09.2025). В результате стало подолгу задумываться после каждой перезагрузки. Включил Memory Context Restore, поставил срок использования данных «тренировки» в 30 дней. Перезагрузки ускорились.

Теперь другая проблема: обновление включило Secure Boot. В результате диски перестали грузиться. Даже когда вручную писал fs0:\EFI\gentoo\grubx64.efi Отключил Secure Boot — всё равно не считает основной HDD загрузочным (как если бы на нём отсутствовал раздел efi-boot), но хотя бы удалось загрузиться через шелл.

question4
()

Intel Arc Pro B65 в качестве видяхи для локальной LLM?

 , intel arc, llama-cpp,

Привет!

Я тут немного приобщился к прогрессу, позапускал локальные модели с llama-cpp. Поскольку у меня нет дискретной видяхи (AMD Ryzen 5 PRO 4650G), то более-менее нормальные модели (типа Qwen_Qwen3.6-35B-A3B-Q4_K_L.gguf) работают очень медленно. И подумалось мне, что надо бы видяху. И наткнулся я в ДНС на видяху Intel Arc Pro B65 аж с 32Гб ОЗУ, за довольно небольшие по нынешним временам 110 тыр. Но есть сомнения, будет ли работать, и не выкину ли я деньги на ветер.

Поэтому вопросы: кто-то пробовал (эту видяху или похожие)? Как у неё с линуксом и с llama-cpp? Есть ли драйвер в убунте? Ну и в целом - отговорите/сагитируйте - стоит ли пытаться запускать локальные LLM, или лучше купить подписку и не париться?

Beewek
()

А не пора ли разрешить webp на аватарки?

 ,

Сабж. Ну или принудительное перекодирование в него на стороне сервера ввести. ИМХО уже все браузеры в него умеют. А картинки всяко меньше, что приятно при плохом инете. Или будем ждать когда jpeg xl начнёт везде поддерживаться и уже на него переезжать?

peregrine
()

Комплекс Физических Программ / Makarov Physics Suite

 , , ,

Выложил исходники программы по моделированию физических процессов, которую разработал на втором курсе вуза (в 2004 году):

https://github.com/makarov-mm/MakarovPhysics

--------------------------

Также в открытом доступе некоторое количество программ по физике:

https://buymeacoffee.com/makarovmm/posts

--------------------------

Видео свежей разработки (не опенсорс):

https://www.youtube.com/watch?v=3L69oUlDxOE

( ещё )

makarov
()

Посоветуйте Бюджетную железку

 ,

Коллеги , а посоветуйте бюджетную железку, можно ит Б/у , чтобы:

  • Было помощнее чем mikrotik RB750Gr3 r4
  • два и более ethernet порта
  • опционально 3-4 порта POE
  • openwrt или Linux/FreeBSD
pinachet
()

Как отговорить себя от написания своей ФС

 , high performance,

Моя идея о том, чтобы переписать наш Flussonic с Erlang на Rust оказалась совершенно прекрасной и у меня совершенно прекрасные результаты. Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Однако трафик записи в 16-17 гигабит на 38 шпинделей - не предел возможности диска, это порядка 420 мегабит, а в теории шпиндель может принять и до 2 000 мегабит.

Единственная мысль, которая осталась после всех оптимизаций (выравнивание по границе блока, fadvise) - это хранение данных в одном файле в interleaved режиме, т.е. все камеры на одном диске держать в одном файле.

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

Давайте 3 причины не лезть в этот блуд.

max_lapshin
()

Как настроить VS Code из Flatpak для разработки на Go?

 , ,

По мотивам недавних событий пакет visual-studio-code-bin выкинули из AUR, соответственно из доступного остался Flatpak. Поставил оттуда, но настроить сабж для работы с тулчейном, словарями и прочим привычным в случае нативного пакета далеко не очевидно, например, пакет hunspell оно не видит и сразу сыпет ошибками, стоит написать комментарий на русском, например. С тулчейном тоже не совсем очевидно как быть, плюс настройка доп. утилит типа отладчика, генератора интерфейсов и всего такого.

Если есть такой опыт, поделитесь, пожалуйста.

LongLiveUbuntu
()

Листание картинок

 ,

Смотрим например Linux-десктоп с Hyprland, картинки листаются циклически нормально, обоими стрелками.
А вот в Обезгугленные. Альт мобильный на Oneplus 6T., левой стрелкой листается циклически, а правой только до последней.
Это так и задумано?

GAMer
()

Китайские Android TV-приставки H96 использовали для накрутки рекламы и в качестве домашних прокси

 , , ,

Специалисты Bitsight TRACE раскрыли устройство ботнета Fuyao, который использует недорогие Android TV-приставки для автоматической накрутки рекламных просмотров и кликов, а также в качестве резидентских прокси. Исследователи пришли к выводу, что приложения Fuyao поставлялись предустановленными на некоторых приставках H96, вероятно в составе модифицированных прошивок. В качестве возможных каналов такой установки называются кастомизация со стороны OEM/дистрибьютора или реселлера и распространение модифицированных ROM для самостоятельной перепрошивки.

Расследование началось с обнаружения оставленного в прошивках механизма удалённого администрирования. Приставки продолжали обращаться к домену, регистрация которого истекла; после его перехвата исследователи получили телеметрию с моделью устройства, версией прошивки, характеристиками оборудования, MAC-адресом и списком установленных Android-пакетов. Именно благодаря этому удалось одновременно увидеть системный пакет sysserver.systemUpdate и приложения Fuyao.

Наиболее конкретно в отчёте фигурирует H96 Max V11. Один из полученных отчётов идентифицировал устройство как H96_Max_V11 с Android 11; исследователи отмечают, что приложения Fuyao чаще всего обнаруживались именно на H96_MAX_V11. При этом сами авторы предупреждают, что статистика может быть смещена: захваченный ими домен давал видимость преимущественно по старым моделям приставок одного бренда.

За 24 часа через перехваченный сервер прошло 65 957 отчётов примерно от 38 тыс. уникальных MAC-адресов, на которых были обнаружены приложения Fuyao. Однако Bitsight специально оговаривает, что 38 тыс. MAC-адресов нельзя автоматически считать 38 тыс. физических приставок: система умеет подменять идентификаторы устройств. С другой стороны, наблюдение охватывало лишь часть инфраструктуры, поэтому реальное число задействованных устройств может быть больше.

После получения задания приставка могла маскироваться под обычный смартфон: Fuyao подменяет системные свойства Android, сведения об аппаратной платформе и параметры браузерного окружения. В перехваченных данных TV-боксы представлялись устройствами Samsung, Xiaomi, Huawei, Vivo и других производителей. Цель такой маскировки — получить более дорогие рекламные показы и клики и одновременно усложнить обнаружение автоматизированного трафика.

Для поиска рекламных элементов используется несколько механизмов — Android Accessibility, OCR и модели компьютерного зрения. В более новых версиях Fuyao разработчики перешли от преимущественно JavaScript-автоматизации к использованию предварительно обученных ML-моделей. В коде также обнаружены заготовки для Azure GPT-4o, предназначенные для принятия решений о том, куда нажимать и куда переходить дальше, однако на момент исследования этот механизм фактически не был подключён к рабочей цепочке.

Особый интерес представляет система создания сценариев рекламного мошенничества. Операторы построили собственный редактор на базе свободной библиотеки Blockly, распространяемой под Apache 2.0. В визуальном редакторе можно задать целевой сайт, параметры браузера, вероятность клика, очистку кэша, bounce rate и другую логику кампании. После сохранения блоки преобразуются в JavaScript и отправляются на приставки. Bitsight обнаружила около 56 исходных модулей, а в ходе наблюдения получила уже порядка 166 уникальных модулей, включая 109 вариантов логики для конкретных сайтов.

Монетизация не ограничивалась рекламой. Приложение Center превращает приставку в резидентский SOCKS5-прокси, через который может проходить чужой сетевой трафик с использованием домашнего IP-адреса владельца. За одни сутки с известной Bitsight инфраструктурой резидентских прокси пересекалась примерно одна из шести наблюдавшихся приставок Fuyao, а за семь дней — примерно одна из четырёх. Более 90% устройств, работавших только как прокси, имели установленным приложение Center.

Любопытно и распределение нагрузки: анализ функции CheckSelf() показал, что при активном HDMI приставка преимущественно используется как прокси, а когда HDMI неактивен — запускает задачи по накрутке рекламы. Таким образом, вредоносная активность может выполняться преимущественно тогда, когда телевизор фактически не используется владельцем.

Приложения способны не только выполнять удалённые задания, но и передавать на управляющий сервер журналы работы, периодические снимки экрана и даже видеопоток экрана через WebRTC. Управление построено на нескольких уровнях C2-серверов и постоянных WebSocket-соединениях.

Bitsight связала Fuyao с китайской компанией Zhejiang Fengwo IoT Technology Co., Ltd, входящей в Fengwo Group. Исследователи называют четыре независимые группы признаков: пересечение TLS-сертификатов, файлы из внутренней wiki, связи с компаниями, использовавшимися для получения рекламных выплат, и зарегистрированные в Китае патенты. По данным Bitsight, как минимум 6–8 патентов напрямую соответствуют подсистемам, обнаруженным при анализе Fuyao.

Связанная с Fengwo инфраструктура рекламировала более 120 тыс. «AI digital humans». Это число не следует путать с независимо подтверждённым размером ботнета: 120 тыс. — заявление самой компании, тогда как через захваченный Bitsight сервер исследователи наблюдали около 38 тыс. уникальных MAC-адресов. На основе условных десяти кликов по $0,10 и дохода от показов авторы оценили теоретическую выручку сети из 120 тыс. устройств примерно в $150 тыс. в сутки, отдельно предупредив, что часть трафика может отбрасываться антифрод-системами.

H96 Max V11 продаётся на российских маркетплейсах

Названная исследователями модель не является какой-либо редкой китайской приставкой. На момент проверки 8 августа H96 Max V11 продолжает продаваться в России. На Ozon размещена карточка H96 Max V11 на Android 11, а на Wildberries продаётся H96 Max V11; присутствуют и другие предложения этой модели, включая вариант H96 MAX V11 4/64 ГБ. В карточках указывается процессор Rockchip RK3318 и Android 11.

Те же характеристики приводит и официальная страница H96 Max V11: RK3318, Android 11 и варианты с 2/4 ГБ ОЗУ и 16/32/64 ГБ встроенной памяти. Производитель отдельно предлагает OEM/ODM-кастомизацию, в том числе изменение boot image, launcher, интерфейса, функций и состава приложений прошивки. Это согласуется с предположением Bitsight о возможности появления Fuyao на этапе кастомизации ROM, но само по себе не является доказательством участия производителя H96 в установке вредоносного ПО.

Важно также не переносить выводы исследования на все продающиеся H96 Max V11. Bitsight обнаружила Fuyao на устройствах с таким идентификатором модели и пишет, что приложения чаще всего встречались именно там, однако не исследовала партии конкретных российских продавцов. Поэтому по одной карточке на Ozon или Wildberries определить наличие Fuyao невозможно — оно зависит от конкретной прошивки и цепочки поставки.

unclestephen
()

Посоветуйте серверный дистр для VDS с одним гигом

 , , ,

Привет. У меня работает VDS с одним гигом, и, судя по всему - оперативки не хватает для нормальной работы: глючит всё - и убунта, и лайвы, и Минт и др. Начинал я с Убунты 18, но современная 26 не заработала (естесснно). Но я хочу современный дистрибутив. Люди мне советуют всякие легковесные, но - десктопные, а мне, как-то, не надо. Да - я мог-бы иметь возможность запускать графику по желанию, но серверный пакет предполагается «ближе к телу». Собственно из задач: прокси-сервер (для чего, собственна, я его и покупал)(потому и мало оперативки, - дешёвый); развлекухами идут сайты, хранилище… Убунту советовали как лёгкий для новичка. Прошу посоветовать удобный серверный дистрибутив, современный, для малой оперативы.

Levontay
()

Бинарный патч ядра

 , , ,

Вводные: ядро от стоковой Android прошивки устройства на MediaTek. Исходников нет. Цель: пропатчить уже собранное ядро, чтобы оно не забирало bootargs из device tree или загрузчика, но использовало свои из header.

Маловероятно, но есть тут кто шарит за подобное? Может есть у кого опыт. Или, может, кто-то знает профильные форумы\статьи.

Retard
()

Linux наконец-то не тормозит или пятничный релакс

 , ,

Помню давние времена, это был Debian 4, прекрасные третьи кеды, Celeron, HDD диски, какой-то древний GeForce и летающий Linux.

Прошли десятилетия. Из статьи в статью копипастится мантра «Linux для слабого железа», так же она повторяется и в комментариях, непременно сопровождаясь аннотацией «Пишет Вася, 32 Gb RAM, SSD Tb, GeForce RTX 5060 Ti». А я тем временем наблюдаю на своем железе какую-то ужасающую деградацию работы десктопного линукса. И если лет 5 назад это еще не так заметно было, то в последние года два это совсем уже из ряда вон выходящее и описывается одним словом: «безбожно тормозит». Разумеется мне эксперты вторят в один голос дескать у меня руки кривые. Возможно. Но что-то то мне подсказывало, что дело то не совсем в руках, ведь пользуюсь я линуксом то давненько и почему-то раньше, когда был менее опытным, все работало хорошо из коробки.

Итак, я консервативный технический аскет, мое домашнее железо сейчас это HDD (ни разу не покупал домой SSD), средненький проц и 8Gb RAM, видеокарта GTX 970. Это позволяет видеть проблемы сразу, собственно инженеры подтверждают этот тезис, см. https://news.ycombinator.com/item?id=41499633. Я начал искать, почему я наблюдаю отчетливо плохую работу домашней системы на современных дистрибутивах Linux. Первой проблемой стал snap. На таком железе всякие mint и ubuntu ушли в мусорку очень быстро, так как там используется оный, а это мазохизм, если у тебя не SSD и куча оперативы (да и вообще явный продукт копроэкономики). С flathub получше, но тоже нет. Эсперты на этом месте скажут «Ты что идиот? Купи SSD, HDD это прошлый век». У меня бывают долгие отсутствия или я могу попросту положить HDD на полку. С HDD я уверен что данные останутся, с SSD нет, см. статью о потере данных без питания у SSD https://www.ixbt.com/news/2025/04/20/dva-goda-bez-pitanija-issledovanie-podtverdilo-riski-dolgosrochnogo-hranenija-dannyh-na-ssd-bez-pitanija.html. А еще прекрасное, в век LLM SSD теперь ушатываются на раз https://4pda.to/2026/06/23/457958/nejroset_codex_okazalas_sposobna_ubit_ssd_menshe_chem_za_god/. Разумеется я не стал использовать всякие BTRFS, ZFS, XFS и подобные фс, которые уже давно заточены под SSD. Оставил ext4.

А дальше явных проблем я не нашел. Но как быть, если сетап окружения примерно такой же как раньше (использую браузер и IDE), а результат разный в разы? Ну не может же быть дело только в HDD, откуда бы такая деградация. Оказывается видимо может. Я нашел прекрасный тред https://www.linuxquestions.org/questions/slackware-14/disk-thrashing-on-5-15-x-kernels-but-not-on-4-4-x-or-4-19-x-kernels-4175713190/. В общем тенденция такова, что корпы очень сильно отравляют ядро в угоду корпоративным интересам (и корпоративного уровня железа), а домашнее железо игнорят или не сильно на него обращают внимание и с каждой свежей версией ядра на домашнем железе работа Linux деградирует. Видимо сейчас накопилось достаточно проблем, чтобы это стало визуально заметно. Что там напихали со времен 5.15 ядра, каких регресионных изменений, бог его знает, заниматься этим нет ни времени ни желания.

И я решил провести эксперимент, и поставли Debian 10 c бекпортами (ядро 4.19), форматнул с ext2(boot) и ext3, накатил Trinity Desktop https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions#TDE_R14.1.x_series и о чудо, все залетало! Браузер и IDE стали открываться мгновенно, сайты работают шустро, графическая оболочка откликается молниеносно, ощущения что я вернулся во времена Debian 4!

А что насчет старого софта спросите вы, а что, вы не умеет собирать свежий софт из исходников?…

Итого, сижу и наслаждаюсь старым добрым Linux в пятницу и в очередной раз читаю экспертов на сайтах: «У тебя руки кривые, у меня все работает на моей Ubuntu». Разумеется, они абсолютно правы. Всем добра :)

P.S. Жду клоунов в реакциях

Перемещено hobbit из talks

nullb0t
()

RSS подписка на новые темы