https://www.opennet.me/openforum/vsluhforumID3/101107.html Представлена (http://curl.haxx.se/mail/archive-2015-01/0019.html) новая версия утилиты для организации выборки данных по сети - cURL 7.40.0 (http://curl.haxx.se/), предоставляющей возможность гибкого формирования запроса с заданием таких параметров, как cookie, user_agent, referer и любых других заголовков. cURL поддерживает HTTP, HTTPS, HTTP/2.0, SMTP, IMAP, POP3, Telnet, FTP, LDAP, RTSP, RTMP и другие сетевые протоколы. Одновременно вышло обновление параллельно развиваемой библиотеки libcurl, предоставляющей API для задействования всех функций cURL в программах на таких языках, как Си, Perl, PHP, Python. <br><br><br><br>Основные новшества (http://curl.haxx.se/changes.html#7_40_0):<br><br><br>- Начальная поддержка протокола SMB/CIFS, что позволяет использовать curl для прямого обращения к ресурсам файловых серверов на базе платформы Windows (путь к файлу задаётся в виде "smb://domain%2fuser:password@server.example.com/путь"). <br>- Возможность отправки HTTP-запросов поверх доменных Unix-сокетов (путь к сокету следует передав https://www.opennet.me/openforum/vsluhforumID3/101107.html#67 Wed, 14 Jan 2015 00:28:52 GMT А webkit при этом точно собрался (/usr/libQtWebKit.so.*)?<br>Собирал qt-5.2.0 вручную. Единственный возможный вариант была сборка без webkit. Может в gentoo есть специальные патчи для избавления webkit от ruby? Если так, то киньте ссылку.<br> https://www.opennet.me/openforum/vsluhforumID3/101107.html#66 Tue, 13 Jan 2015 22:53:41 GMT &gt; Да верно - его тянет за собой webkit. Но не как опцию, <br>&gt; а как обязательную зависимость. Там действительно часть движка на ruby написана, <br>&gt; так что так просто не отпилишь.<br><br>Зуб даю, в тот раз удалось без проблем отпилить. Запомнил это потому, что параллельно с обновлением своей системы подготавливал специализированный LiveCD на основе stage3, который еле влепил в 700мб (да, кое где ещё пользуются CD-R, не спрашивайте). Гарантирую, с руби на борту этого бы не удалось. Вроде версия Qt была 5.2. Возможно, спасла магия USE-флагов, благодаря которой не стали собираться зависимые от руби части вебкита.<br> https://www.opennet.me/openforum/vsluhforumID3/101107.html#65 Tue, 13 Jan 2015 21:45:42 GMT Да верно - его тянет за собой webkit. Но не как опцию, а как обязательную зависимость. Там действительно часть движка на ruby написана, так что так просто не отпилишь. <br> https://www.opennet.me/openforum/vsluhforumID3/101107.html#64 Tue, 13 Jan 2015 17:32:00 GMT &gt;&gt; &lt;offtop&gt;Вопрос на уроке информатики: Дети, кто знает, зачем Qt тянет за собой Ruby?&lt;/offtop&gt;<br><br>Ухаха, я знаю: там то ли какой-то браузерный компонент (жаваскрипт движок вроде), то ли документация к нему требуют в системе наличия этого самого руби для сборки Qt из исходников. Выяснил это, когда пытался собрать свежие Qt на моей уютной генте. И ужаснулся, когда в зависимостях увидел ЭТО. Тогда всё разрешилось клонированием ебилда в локальный репозиторий и удалением оттуда одной строки, обьявляющей руби как зависимость. На удивление, всё собралось.<br> https://www.opennet.me/openforum/vsluhforumID3/101107.html#63 Mon, 12 Jan 2015 11:52:33 GMT Нет и не планируется. Реализуется всякими сторонними скриптами.<br> https://www.opennet.me/openforum/vsluhforumID3/101107.html#62 Sat, 10 Jan 2015 18:23:22 GMT &gt; Разве что места на диске. Потреблять _много_ памяти - дурной тон даже <br>&gt; для комбайнов.<br><br>Боюсь, что hello world на qt, сожрет больше памяти, чем ядро со всеми драйверами для дескотпа ;)<br><br>&gt; Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых <br>&gt; задач, чем требовать возни с компоновкой модулей при любом раскладе.<br><br>Верно, но компоновать нужно по задаче - нужны кодаки - возьму ffmpeg. Нужны базовые сетевые протоколы - возьму curl. И т.д. Нет смысла компоновать слабо связанные задачи в одну библиотеку.<br><br>&gt; Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший <br>&gt; сумарный объем кода - в комбайне, в котором совместное использование всяких <br>&gt; общих функций проще, или в десятке-другом независимых проектов?<br><br>Пример: нужен простой видео плеер с поддержкой http и выводом через opengl. <br>Вариант 1: ffmepg+curl+glfw.<br>Вариант 2: Qt(+куча зависимостей) + ffmpeg.<br><br>Где меньше сумарный объем кода?<br><br>&gt;&gt; Изменить в ней что-то достаточно сложно - н https://www.opennet.me/openforum/vsluhforumID3/101107.html#61 Sat, 10 Jan 2015 17:58:07 GMT &gt; Попробуйте построить десктопный дистрибутив <br>&gt; на основе busybox - проникнетесь ;) <br><br>Уже :) Последние лет пять на busybox (без udev/dbus/etc).<br><br>&gt; Все это можно применить и к ядру Linux.<br><br>Нет, неприменимо - в ядре есть oss и alsa, куча планировщиков, ФС. Выбрать можно, что угодно - на остальные подсистемы это не повлияет. Тем более что разработку можно вести вне ядра и подгружать/заменять модули.<br><br>&gt; весьма демагогично. Попробуйте заменить в Gentoo OpenRC на SysVinit. Подсказка: OpenRC <br>&gt; использует свой формат скриптов, несовместимых с SysV, поэтому вам придется переписать <br>&gt; скрипты для всех демонов.<br><br>Скрипты - неотъемлемая часть системы инициализации, это ее система конфигурации. Из системных компонентов обычно заменяют только init, остальное используют то, что есть в системе. А не пишут свой логер/dns сервер и т.д, которые завязан на systemd так, что не могут работать в других системах инициализации.<br><br>&gt;&gt; Посмотрите пример с сеткой <br>&gt; Где?<br><br>Нету ссылку дал, вот правильная:<br>http://www.opennet https://www.opennet.me/openforum/vsluhforumID3/101107.html#60 Sat, 10 Jan 2015 17:43:46 GMT &gt; без полноценной (читай bloatware)<br><br>bloatware == полноценность?<br> https://www.opennet.me/openforum/vsluhforumID3/101107.html#59 Sat, 10 Jan 2015 17:40:07 GMT &gt; Проблема bloatware - чрезмерное потребление ресурсов <br><br>Разве что места на диске. Потреблять _много_ памяти - дурной тон даже для комбайнов.<br><br>&gt; и отсутствие гибкости. <br><br>Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых задач, чем требовать возни с компоновкой модулей при любом раскладе.<br><br>&gt; Большая кодовая база ведет к большому количеству багов.<br><br>Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший сумарный объем кода - в комбайне, в котором совместное использование всяких общих функций проще, или в десятке-другом независимых проектов?<br><br>&gt; Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование. <br><br>Спорно.<br>Если взять комбайн и разбить его на сотню "независимых" проектов - все равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка за миску риса, которой на все пофиг), и тестировать конечный продукт, поскольку полной независимости обеспечить невозможно, и баг в одн