Представлена (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.Основные новшества (http://curl.haxx.se/changes.html#7_40_0):
- Начальная поддержка протокола SMB/CIFS, что позволяет использовать curl для прямого обращения к ресурсам файловых серверов на базе платформы Windows (путь к файлу задаётся в виде "smb://domain%2fuser:password@server.example.com/путь").
- Возможность отправки HTTP-запросов поверх доменных Unix-сокетов (путь к сокету следует передаваться через CURLOPT_UNIX_SOCKET_PATH или --unix-socket).
- Поддержка основанной на GSS-API аутентификации через Kerberos V5
- Поддержка "http digest"-аутентификации с использованием Windows SSPI.
- Для SSL обеспечена поддержка формата PEM для привязки открытых ключей.
- Поддержка SMTP расширена возможностью преобразования новых строк при отправке почтовых сообщений.- Устранены две уязвимости: возможность (http://curl.haxx.se/mail/archive-2015-01/0021.html) подстановки URL при запросе через прокси и пропуск (http://curl.haxx.se/mail/archive-2015-01/0020.html) проверки сертификата darwinssl.
URL: http://curl.haxx.se/mail/archive-2015-01/0019.html
Новость: http://www.opennet.me/opennews/art.shtml?num=41416
Что-то не совсем понятно ее назначение. Что-то типа Wget?
верно. часто использовалась в рпм дистрах в качестве качалки rpm перед установкой. вместе с aria и wget. но по опыту тупил curl тоже весьма часто и привередлив зараза. поэтому предпочитаю wget/
> Что-то не совсем понятно ее назначение. Что-то типа Wget?А теперь еще типа smbclient и sendmail.
Должен остаться только один!
останется фаерфокс.
Останется только systemd.
> Останется только systemd.Вам шашечки или ехать?
Тaщемта, systemd уже давно требует по зависимостям libcurl.
Похожа на wget, но больше возможностей, например может не только скачивать, но и отсылать (curl -X POST).Да и в первую очередь проект интересен библиотекой, а не утилита. В D ее вообще в стандартную библиотеку включили.
> Похожа на wget, но больше возможностей,Как насчет аналога wget -r?
Нет и не планируется. Реализуется всякими сторонними скриптами.
> Что-то не совсем понятно ее назначение. Что-то типа Wget?А также либа через которую все то же самое можно в софте. Порой удобно.
Ценность в либе, которая позволяет автоматизировать серфинг с определенными целями. ;)
курл наше все!
> Ценность в либе, которая позволяет автоматизировать серфинг с определенными целями. ;)
> курл наше все!Зачем, если есть LWP::Simple и LWP::UserAgent?
> Что-то не совсем понятно ее назначение. Что-то типа Wget?Скажу чем интересна она мне - широкая возможность ковыряния удаленных web сервисов с помощью посылки спец. сфор. запросов, анализ выдаваемых заголовков и т.д. - т.е. по сути некая отладка, что-ли.
Причем из CLI, без призыва лишних сущностей
http://daniel.haxx.se/docs/curl-vs-wget.html
> http://daniel.haxx.se/docs/curl-vs-wget.htmlСразу напомнило http://0pointer.de/blog/projects/why
:)
>> http://daniel.haxx.se/docs/curl-vs-wget.html
> Сразу напомнило http://0pointer.de/blog/projects/why
> :)Всегда напоминало:
http://blog.hidexter.com/?p=444
А wget может по https, да ещё и с прикреплённым сертификатом отправить POST-запрос, а потом ещё считать и вернуть ответ?
Curl вообще не позиционируется как качалка, это лишь одна из его побочных возможностей.
> Curl вообще не позиционируется как качалкаСкажите это комментаторам выше :)
Кто-нибудь знает, как он аутентифицирует SMB, если в AD-домене напрямую пароли не передаются, только тикеты?
Возможно задействует smbclient аналогично файловым менеджерам, не?
> Возможно задействует smbclient аналогично файловым менеджерам, не?Нет, вроде за собой ничего не тянет. Да и смысл ведь в том, что можно будет на любом embedded работать с smb/cifs без полноценной (читай bloatware) samba.
> без полноценной (читай bloatware)bloatware == полноценность?
> If you use a Windows SSPI-enabled curl binary and perform Kerberos V5, Negotiate, NTLM or Digest authentication then you can tell curl to select the user name and password from your environment by specifying a single colon with this option: "-u :".
ждем когда поддержка торрент появится)
прикололся?)) там ща везде вроде aria2 рулит. хотя я предпочитаю wget. сделаем из curl новый скайп с торрентом и плюшками))) ахахах . вот ребятам заняться нечем. реально. идеология юникс же вроде одной задаче одна программа)0 причем маленькая программа, а они из линуха вторую винду сделать хотят))
с разморозкой. Ваш КО :)
> прикололся?)) там ща везде вроде aria2 рулит. хотя я предпочитаю wget.И как, много торрентов wget'ом удалось скачать? :)
И да, вы знаете, торрент умеет проверку целостности и перекачку битых блоков. Не говоря уже о скачке группы файлов за раз, многопоточности и прочая.
> идеология юникс же вроде одной задаче
> одна программа)0 причем маленькая программа, а они из линуха вторую винду
> сделать хотят))Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel. И curl тоже - можно отключить все не нужное и получить очень компактный вариант. А если учесть, что curl - это в первую очередь библиотека для работы с разнообразными сетевыми протоколами, то подобный подход более чем оправдан.
теперь будем все дружно делать библиотеки и потом морды к ним? типа давайте сделаем одну чтоб описывала все что можно сделать алгоритмически )) и скажем вот вам 1 библиотека на1,5 гига а вы ребята теперь делайте морды как хотите, но чтоб только маленькие)) это ж юникс. нет я понимаю что они хотят расширить возможности программы, но зачем пихать в неё то что уже имеется.
> теперь будем все дружно делать библиотеки и потом морды к ним? типа
> давайте сделаем одну чтоб описывала все что можно сделать алгоритмически ))
> и скажем вот вам 1 библиотека на1,5 гига а вы ребята
> теперь делайте морды как хотите, но чтоб только маленькие)) это ж
> юникс. нет я понимаю что они хотят расширить возможности программы, но
> зачем пихать в неё то что уже имеется.всякие жабы и миNETы практически так и устроены
Сделать можно очень по-разному. Можно хорошо (примеры я уже привел), можно не очень (Qt).Что касается конкретно curl: любой протокол можно отключить (на стадии компиляции), реализация каждого протокола от 5KB до 200KB, smb - 34KB. При этом мы получаем унифицированный API (сходный для всех протоколов) и мультиплатформенность. Для сравнения - samba (весь исходник) - 115MB. Вот это точно unix way :)
Еще как хороший пример вспомнился ffmpeg. Или вы его предлагаете распилить на 200 пакетов и в каждом свой API, то-то разработчики плееров обрадуются :)
del
конкретно тут я бы сказал что есть smbclient)) ffmpeg согласен распиливать не надо.
> конкретно тут я бы сказал что есть smbclient))Но зачем тянуть еще какой-то libsmbclient и кучу его зависимостей (libcap2 , libcomerr2, libgssapi-krb5, libk5crypto3, libkrb5, libldap, libtalloc2, libtdb1, libwbclient0, zlib1g), если необходимый функционал можно просто включить в libcurl?
> ffmpeg согласен распиливать не надо.
Да ничего не надо распиливать. Комбайны практически всегда удобнее, чем нагромождение "модульных" костылей, которое в итоге превращается в такой же комбайн, но хрупкий и переусложненный из-за кучи скриптового "клея" и лени разработчика (ему лень писать нормальный код в своих скриптах, и уж тем более лень документировать что-то).
> Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel.Подобные исключения наглядно подтверждают некорректность правила.
Иными словами, в теории рулят маленькие программки, а на практике - жирные комбайны.
>> Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel.
> Подобные исключения наглядно подтверждают некорректность правила.
> Иными словами, в теории рулят маленькие программки, а на практике - жирные
> комбайны.На практике важна правильная постановка задачи проекта.
kernel и busybox: эти два пакета в состоянии обеспечить минимальную, но полноценную систему. Один отвечает за взаимодействие с железом, второй - с пользователем.
ffmepeg: предоставляет единый API к сотне кодеков.
curl: предоставляет единый API к распространенным сетевым протоколам.Что общего у всех этих проектов? Они предоставляют компактные и простые реализации отдельных компонентов (драйвера/утилиты/кодеки/протоколы), при этом компоненты слабо связаны - могут быть использованы друг без друга или заменены альтернативными проектами/библиотеками.
С точки зрения unix way эти проекты тоже не совсем "неправильные". Они хорошо выполняют свою конкретную функцию - предоставляют единый кросплатформенный API для узко специфической задачи и легко интегрируются в другие проекты. Конечно они могли бы тянуть за собой сторонние реализации, но тогда они станут прослойкой, перестанут быть компактными и легко портируемыми.
Антипримеры:
Qt/systemd - вбирают в себе все что приглянется не придерживаясь четкой специфики, не заботясь об возможности использования отдельных компонентов (без всех остальных), да
и сами компоненты часто не попадают под определение простых и компактных. В добавок тянут еще и внешние зависимости. <offtop>Вопрос на уроке информатики: Дети, кто знает, зачем Qt тянет за собой Ruby?</offtop>Gnome/Xorg - вроде модульные, но по факту для сборки минимального gtk нужен еще десяток пакетов. Тоже и для xorg-server, только пакетов десятки. Отдельно эти пакеты (без gtk/xorg-server) никто не использует, заменить их нечем, да и незачем. Смысл их держать отдельно? Это лишь усложняет сборку: каждые пакет тянет с собой систему сборки (запуск configure длится во многих пакетах дольше, чем сама сборка), пакеты ругаются друг на друга из-за не подходящих версий, нужно искать подходящие версии.
Противоречите сами себе.Например, тот же systemd прекрасно подпадает под определение kernel/busybox - обеспечивает минимальную полноценную систему, промежуточный уровень между ядром и UI (внезапно, такой уровень есть). init, системный журнал, DNS, синхронизация времени, учет пользовательских сеансов и т.д., с возможностью опционального включения тех или иных модулей. Тем не менее, вы относите его к классу "антипримеров".
Опять же "компоненты слабо связаны - могут быть использованы друг без друга или заменены альтернативными проектами/библиотеками" - попробуйте заменить модуль ядра Linux на альтернативную реализацию из ядра FreeBSD, используя только опции сборки, скриптовый клей и прочие unix-way инструменты, без "редактирования сорцов в стиле системд". Слабо?
> Например, тот же systemd прекрасно подпадает под определение kernel/busybox -
> обеспечивает минимальную полноценную систему,которая тянет за собой d-bus, udev и прочее, но не обеспечивает нормальную работу пользователя без *nix utils
> промежуточный уровень между ядром и UI (внезапно, такой
> уровень есть).для которого вполне достаточно возможностей busybox
> init, системный журнал, DNS, синхронизация времени, учет пользовательских
> сеансов и т.д., с возможностью опционального включения тех или иных модулей.
> Тем не менее, вы относите его к классу "антипримеров".Потому что нельзя использовать logind без того чтобы не притянуть остальной systemd/d-bus/etc.
> Опять же "компоненты слабо связаны - могут быть использованы друг без друга
> или заменены альтернативными проектами/библиотеками" - попробуйте заменить модуль ядра
> Linux на альтернативную реализацию из ядра FreeBSD,Некорректно поставлено условие. В ядре можно использовать модули по-раздельности (слабо зависят друг от друга) и можно подгружать альтернативные, не входящие в ядро. Можно заменить почти все части ядра - звуковую подсистему/планировщики/etc.
> которая тянет за собой d-bus, udev и прочееНе тянет, а включает в себя. kdbus в основном в ядре, но для его работы нужна ответная часть в юзерспейсе, реализованная в systemd.
> но не обеспечивает нормальную работу пользователя без *nix utils
Помимо обеспечения нормальной работы пользователя, нужно обеспечивать еще и нормальную работу программ. Неожиданно, да?
init, IPC, системный журнал, сеть и прочее - не являются прямо необходимыми для работы пользователя. Ему достаточно init=/bin/sh. Но почему-то так работать никто не хочет.> для которого вполне достаточно возможностей busybox
В подавляющем большинстве случаев - нет.
> Потому что нельзя использовать logind без того чтобы не притянуть остальной systemd/d-bus/etc.
Некорректно поставленное условие. Модули systemd можно использовать по-раздельности (слабо зависят друг от друга) - например, просто собрать systemd без logind, и все остальные компоненты будут нормально работать.
Попытка использования logind без systemd подобна попытке использования iptables без Linux - в принципе возможно, но придется повозиться.
> Можно заменить почти все части ядра - звуковую подсистему/планировщики/etc.
Не написав и не изменив ни одной строчки сишного кода, да? :)
> Не тянет, а включает в себя. kdbus в основном в ядре, но
> для его работы нужна ответная часть в юзерспейсе, реализованная в systemd.Почему все остальные системы инициализации могут прекрасно обходиться без хаков в ядре?
> Помимо обеспечения нормальной работы пользователя, нужно обеспечивать еще и нормальную
> работу программ. Неожиданно, да?Программы вообще ничего о системе инициализации знать не должны. Если система инициализации подготовила все для нормальной работы пользователя, то программы должны нормально работать, иначе как пользователь сможет нормально работать?
> init, IPC, системный журнал, сеть и прочее - не являются прямо необходимыми
> для работы пользователя. Ему достаточно init=/bin/sh. Но почему-то так работать никто
> не хочет.
> В подавляющем большинстве случаев - нет.Ну и чего не может busybox? И почему все раньше работало, а с приходом systemd оказалось что не могло оно работать?
> В подавляющем большинстве случаев - нет.
Я уже писал длинный пост о systemd vs init, с разбором конкретных реальных ситуаций:
http://www.opennet.me/openforum/vsluhforumID3/100356.html#434Посмотрите пример с сеткой, systemd может эту ситуацию решить? А ведь относительно простая вещь. Тоже и с остальными примерами - в bloatware все хорошо, пока делаешь тоже что и все (и ресурсов не жалко), но если захотел сделать что-то более индивидуальное, то проблем сразу на порядок больше.
>> Потому что нельзя использовать logind без того чтобы не притянуть остальной systemd/d-bus/etc.
> Некорректно поставленное условие. Модули systemd можно использовать по-раздельности
> (слабо зависят друг от друга) - например, просто собрать systemd без
> logind, и все остальные компоненты будут нормально работать.Тогда почему я могу использовать только mdev, заменив весь остальной busybox другими *nix utils (хоть gnu, хоть bsd).
> Попытка использования logind без systemd подобна попытке использования iptables без Linux
> - в принципе возможно, но придется повозиться.iptables - frontend для сетевой части ядра. Проблема же logind и прочих *d - они не могут работать друг без друга.
>> Можно заменить почти все части ядра - звуковую подсистему/планировщики/etc.
> Не написав и не изменив ни одной строчки сишного кода, да? :)Ну да - rmmod xxx, modprobe myCoolXxx :)
Также как я могу заменить gnu ls на ls из busybox или еще какой.
> Почему все остальные системы инициализации могут прекрасно обходиться без хаков в ядре?Не systemd требует хаков в ядре, а развитие ядра требует systemd.
К тому же, systemd - это не только система инициализации. Это base layer of linux userspace.> Программы вообще ничего о системе инициализации знать не должны.
Спорно. Опыт классических UNIX-систем (Mac OS X и Solaris) показывает, что тесная интеграция инита и демонов дает определенные плюсы (сокет-активация, удобный мониторинг, перезапуск без закрытия соединений и т.д.).
> Ну и чего не может busybox? И почему все раньше работало, а с приходом systemd оказалось что не могло оно работать?
Что не может телега? Почему раньше все работало, а с приходом автомобилей оказалось, что не могло оно работать?
systemd более удобен и технологичен, только и всего. Попробуйте построить десктопный дистрибутив на основе busybox - проникнетесь ;)
> Я уже писал длинный пост о systemd vs init, с разбором конкретных реальных ситуаций:
> http://www.opennet.me/openforum/vsluhforumID3/100356.html#394В том посте вы весьма жестко критикуете модель ядра Linux
> Полностью согласен. Рассмотрим дальше: systemd заменяет собой ряд стандартных компонентов, добавляет часть новых. Их нужно использовать (иначе зачем добавлять?) и рано или поздно программы начнут их задействовать. Само по себе это правильно. Но эти компоненты не унифицированы. Я не могу поставить отдельный понравившийся мне компонент, а остальное взять от других проектов. Почему нет претензий к другим системам инициализации? Потому что они заменяют один конкретный компонент и прекрасно взаимодействуют с остальными. Если заменяется несколько компонентов, то это как правило компоненты слабо связаны (могут работать друг без друга) и часто выделяются в отдельные проекты. Стратегия opensource основана на сотрудничестве и разделении труда - каждый сосредотачивается на своем компоненте и использует чужие.
Все это можно применить и к ядру Linux. Кроме того, утверждение
> Почему нет претензий к другим системам инициализации? Потому что они заменяют один конкретный компонент и прекрасно взаимодействуют с остальными.
весьма демагогично. Попробуйте заменить в Gentoo OpenRC на SysVinit. Подсказка: OpenRC использует свой формат скриптов, несовместимых с SysV, поэтому вам придется переписать скрипты для всех демонов.
> Посмотрите пример с сеткой
Где?
> Тогда почему я могу использовать только mdev, заменив весь остальной busybox другими
> *nix utils (хоть gnu, хоть bsd).Потому что в наборе утилит командной строки интеграция не такая сильная, как в модулях ядра или базовой системы.
> iptables - frontend для сетевой части ядра. Проблема же logind и прочих *d - они не могут работать друг без друга.
Проблема iptables - то, что оно не может работать без netfilter :)
> Ну да - rmmod xxx, modprobe myCoolXxx :)
Окей, дайте мне модуль, заменяющий netfilter. Ядро 3.2.63, есличо.
> Также как я могу заменить gnu ls на ls из busybox или еще какой.
Поздравляю, хот что-то вы можете заменить в своей "неблоатварной" системе :)
> Попробуйте построить десктопный дистрибутив
> на основе busybox - проникнетесь ;)Уже :) Последние лет пять на busybox (без udev/dbus/etc).
> Все это можно применить и к ядру Linux.
Нет, неприменимо - в ядре есть oss и alsa, куча планировщиков, ФС. Выбрать можно, что угодно - на остальные подсистемы это не повлияет. Тем более что разработку можно вести вне ядра и подгружать/заменять модули.
> весьма демагогично. Попробуйте заменить в Gentoo OpenRC на SysVinit. Подсказка: OpenRC
> использует свой формат скриптов, несовместимых с SysV, поэтому вам придется переписать
> скрипты для всех демонов.Скрипты - неотъемлемая часть системы инициализации, это ее система конфигурации. Из системных компонентов обычно заменяют только init, остальное используют то, что есть в системе. А не пишут свой логер/dns сервер и т.д, которые завязан на systemd так, что не могут работать в других системах инициализации.
>> Посмотрите пример с сеткой
> Где?Нету ссылку дал, вот правильная:
http://www.opennet.me/openforum/vsluhforumID3/100356.html#434
>> Тогда почему я могу использовать только mdev, заменив весь остальной busybox другими
>> *nix utils (хоть gnu, хоть bsd).
> Потому что в наборе утилит командной строки интеграция не такая сильная, как
> в модулях ядра или базовой системы.Модули ядра слабо зависят друг от друга. Udev может быть заменен на mdev. И как не странно все работает, за исключением systemd ;)
> Окей, дайте мне модуль, заменяющий netfilter. Ядро 3.2.63, есличо.
Не для всех модулей есть аналоги. Но при необходимости их можно написать.
> Поздравляю, хот что-то вы можете заменить в своей "неблоатварной" системе :)
Заменить можно практически все. Было бы желание и поменьше Поттерингов, продвигающих единственно правильное решение :)
Я уже не говорю о том, что Qt - практически единственный вариант для безгеморного создания кроссплатформенных приложений, причем не только графических. Массовый свалинг проектов с Gtk на Qt полностью подтверждает этот тезис.
Qt - это попытка создать нормальную стандартную библиотеку для c++. Лучше на данный момент ничего нет. Но это не значит, что Qt не bloatware и все от нее в восторге.Путь развития gtk3/gnome3 многих не устраивает, вот и бегут, кто назад на gtk2, кто на qt.
> Qt - это попытка создать нормальную стандартную библиотеку для c++. Лучше на данный момент ничего нет. Но это не значит, что Qt не bloatware и все от нее в восторге.Нет, это всего лишь означает, что в ярлыке "bloatware" нет ничего плохого :)
Бессмысленно приводить блоатварность в качестве недостатка, потому что во всех ваших примерах ее реальные плюсы (удобство - вся необходимая функциональность под рукой) перевешивают мнимые минусы (отсутствие "минимализма", который вообще-то мотивирован соображениями скорее эстетическими, нежели практическими).
> Нет, это всего лишь означает, что в ярлыке "bloatware" нет ничего плохого
> :)
> Бессмысленно приводить блоатварность в качестве недостатка, потому что во всех ваших примерах
> ее реальные плюсы (удобство - вся необходимая функциональность под рукой) перевешивают
> мнимые минусы (отсутствие "минимализма", который вообще-то мотивирован соображениями
> скорее эстетическими, нежели практическими).Проблема bloatware - чрезмерное потребление ресурсов и отсутствие гибкости. Большая кодовая база ведет к большому количеству багов. Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование. Не говоря о том, что сборка Qt и подобных, дело отнюдь не десяти минут. Если возникнет необходимость портировать на новую платформу, то проще переписать приложение на другой toolkit, чем портировать Qt.
> Проблема bloatware - чрезмерное потребление ресурсовРазве что места на диске. Потреблять _много_ памяти - дурной тон даже для комбайнов.
> и отсутствие гибкости.
Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых задач, чем требовать возни с компоновкой модулей при любом раскладе.
> Большая кодовая база ведет к большому количеству багов.
Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший сумарный объем кода - в комбайне, в котором совместное использование всяких общих функций проще, или в десятке-другом независимых проектов?
> Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование.
Спорно.
Если взять комбайн и разбить его на сотню "независимых" проектов - все равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка за миску риса, которой на все пофиг), и тестировать конечный продукт, поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда может аукнуться в другом.> Если возникнет необходимость портировать на новую платформу, то проще переписать приложение на другой toolkit, чем портировать Qt.
Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3, который пилят в основном под Linux.
> Разве что места на диске. Потреблять _много_ памяти - дурной тон даже
> для комбайнов.Боюсь, что hello world на qt, сожрет больше памяти, чем ядро со всеми драйверами для дескотпа ;)
> Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых
> задач, чем требовать возни с компоновкой модулей при любом раскладе.Верно, но компоновать нужно по задаче - нужны кодаки - возьму ffmpeg. Нужны базовые сетевые протоколы - возьму curl. И т.д. Нет смысла компоновать слабо связанные задачи в одну библиотеку.
> Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший
> сумарный объем кода - в комбайне, в котором совместное использование всяких
> общих функций проще, или в десятке-другом независимых проектов?Пример: нужен простой видео плеер с поддержкой http и выводом через opengl.
Вариант 1: ffmepg+curl+glfw.
Вариант 2: Qt(+куча зависимостей) + ffmpeg.Где меньше сумарный объем кода?
>> Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование.
> Спорно.
> Если взять комбайн и разбить его на сотню "независимых" проектов - все
> равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка
> за миску риса, которой на все пофиг), и тестировать конечный продукт,
> поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда
> может аукнуться в другом.Если я правлю баг в curl, как это отразится на ffmpeg?
> Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3,
> который пилят в основном под Linux.Выбирают из-за того что он уже портирован. Портировать такой объем кода на новую платформу ради одной программы никто в здравом уме не будет.
>> <offtop>Вопрос на уроке информатики: Дети, кто знает, зачем Qt тянет за собой Ruby?</offtop>Ухаха, я знаю: там то ли какой-то браузерный компонент (жаваскрипт движок вроде), то ли документация к нему требуют в системе наличия этого самого руби для сборки Qt из исходников. Выяснил это, когда пытался собрать свежие Qt на моей уютной генте. И ужаснулся, когда в зависимостях увидел ЭТО. Тогда всё разрешилось клонированием ебилда в локальный репозиторий и удалением оттуда одной строки, обьявляющей руби как зависимость. На удивление, всё собралось.
Да верно - его тянет за собой webkit. Но не как опцию, а как обязательную зависимость. Там действительно часть движка на ruby написана, так что так просто не отпилишь.
> Да верно - его тянет за собой webkit. Но не как опцию,
> а как обязательную зависимость. Там действительно часть движка на ruby написана,
> так что так просто не отпилишь.Зуб даю, в тот раз удалось без проблем отпилить. Запомнил это потому, что параллельно с обновлением своей системы подготавливал специализированный LiveCD на основе stage3, который еле влепил в 700мб (да, кое где ещё пользуются CD-R, не спрашивайте). Гарантирую, с руби на борту этого бы не удалось. Вроде версия Qt была 5.2. Возможно, спасла магия USE-флагов, благодаря которой не стали собираться зависимые от руби части вебкита.
А webkit при этом точно собрался (/usr/libQtWebKit.so.*)?
Собирал qt-5.2.0 вручную. Единственный возможный вариант была сборка без webkit. Может в gentoo есть специальные патчи для избавления webkit от ruby? Если так, то киньте ссылку.
Я даже не знаю, что бы делал без libcurl весь последний год на работе.
Ах это ты SMB прикрутил?! Лучше бы работал, честное слово...
> Ах это ты SMB прикрутил?! Лучше бы работал, честное слово...Не нравится - будь мужиком, сделай форк curl без SMB!
Для SMB используется libsmbclient или свой велосипед?
Судя по confgiure.ac, никаких libsmbclient оно не использует. Значит, свой.
configure: Configured to build curl/libcurl:curl version: 7.40.0
Host setup: i686-pc-linux-gnu
Install prefix: /usr
Compiler: gcc
SSL support: enabled (OpenSSL)
SSH support: no (--with-libssh2)
zlib support: enabled
GSS-API support: no (--with-gssapi)
TLS-SRP support: enabled
resolver: POSIX threaded
IPv6 support: enabled
Unix sockets support: enabled
IDN support: enabled
Build libcurl: Shared=yes, Static=yes
Built-in manual: enabled
--libcurl option: enabled (--disable-libcurl-option)
Verbose errors: enabled (--disable-verbose)
SSPI support: no (--enable-sspi)
ca cert bundle: no
ca cert path: /etc/ssl/certs
LDAP support: no (--enable-ldap / --with-ldap-lib / --with-lber-lib)
LDAPS support: no (--enable-ldaps)
RTSP support: enabled
RTMP support: no (--with-librtmp)
metalink support: no (--with-libmetalink)
HTTP2 support: disabled (--with-nghttp2)
Protocols: DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS POP3 POP3S RTSP SMB SMBS SMTP SMTPS TELNET TFTP
До настоящих мастеров им еще далеко
systemd 218libcryptsetup: yes
PAM: yes
AUDIT: yes
IMA: yes
AppArmor: no
SELinux: yes
SECCOMP: yes
SMACK: yes
XZ: yes
LZ4: no
ACL: yes
GCRYPT: yes
QRENCODE: yes
MICROHTTPD: yes
CHKCONFIG: yes
GNUTLS: no
libcurl: no
libidn: no
ELFUTILS: no
binfmt: yes
vconsole: yes
bootchart: yes
quotacheck: yes
tmpfiles: yes
sysusers: yes
firstboot: yes
randomseed: yes
backlight: yes
rfkill: yes
logind: yes
machined: yes
hostnamed: yes
timedated: yes
timesyncd: yes
default NTP servers: time1.google.com time2.google.com time3.google.com time4.google.com
time epoch: 1419988297
localed: yes
networkd: yes
resolved: yes
default DNS servers: 8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
coredump: yes
polkit: yes
efi: yes
kmod: yes
xkbcommon: no
blkid: yes
libmount: yes
dbus: yes
nss-myhostname: yes
gudev: yes
hwdb: yes
gintrospection: yes
terminal: no
kdbus: no
Python: yes
Python Headers: yes
man pages: yes
gtk-doc: yes
test coverage: no
Split /usr: no
SysV compatibility: yes
compatibility libraries: no
utmp/wtmp support: yes
ldconfig support: yes
hibernate support: yes
extra debugging: none
это из федоры?
Это из CI одного хостинга.
куды написать чтобы приделали pop3, imap и nfs?
pop3 и imap уже.Насчёт nfs пишите в спортлото.
> Насчёт nfs пишите в спортлото.Так вот кто стоит за разработкой curl!
>Начальная поддержка протокола SMB/CIFSOMG! мои мольбы (вообще-то это было скорее тихое нытьё, ну да не важно) наконец-то услышаны!