forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS, opennews (??), 08-Янв-15, (0) [смотреть все] +1

Что-то не совсем понятно ее назначение Что-то типа Wget , Аноним (-), 20:48 , 08-Янв-15, (1) //

верно часто использовалась в рпм дистрах в качестве качалки rpm перед установко, Аноним (-), 20:53 , 08-Янв-15, (2) +6
А теперь еще типа smbclient и sendmail Должен остаться только один , EHLO (?), 21:14 , 08-Янв-15, (3) //

останется фаерфокс , Аноним (-), 22:29 , 08-Янв-15, (6) //

Останется только systemd , Ыр (?), 23:22 , 08-Янв-15, (10)

Вам шашечки или ехать , анонко (?), 01:10 , 09-Янв-15, (15)

Тaщемта, systemd уже давно требует по зависимостям libcurl , Аноним (-), 14:48 , 09-Янв-15, (32)

Похожа на wget, но больше возможностей, например может не только скачивать, но и, Mihail Zenkov (ok), 22:50 , 08-Янв-15, (7) //

Как насчет аналога wget -r , Аноним (-), 14:49 , 09-Янв-15, (33) //

Нет и не планируется Реализуется всякими сторонними скриптами , анонимус (??), 14:52 , 12-Янв-15, (63)

А также либа через которую все то же самое можно в софте Порой удобно , Аноним (-), 00:13 , 09-Янв-15, (12)
Ценность в либе, которая позволяет автоматизировать серфинг с определенными целя, Антоним (ok), 11:32 , 09-Янв-15, (29) //

Зачем, если есть LWP Simple и LWP UserAgent , Аноним (-), 14:51 , 09-Янв-15, (34)

Скажу чем интересна она мне - широкая возможность ковыряния удаленных web сервис, edwin3d (ok), 11:48 , 09-Янв-15, (31)
http daniel haxx se docs curl-vs-wget html, dolbokluv (?), 10:18 , 10-Янв-15, (47) //

Сразу напомнило http 0pointer de blog projects why , Аноним (-), 18:25 , 10-Янв-15, (51) //

Всегда напоминало http blog hidexter com p 444, EHLO (?), 18:45 , 10-Янв-15, (52) +1

А wget может по https, да ещё и с прикреплённым сертификатом отправить POST-запр, Ilya Indigo (ok), 16:18 , 10-Янв-15, (48) //

Скажите это комментаторам выше , Аноним (-), 20:11 , 10-Янв-15, (56)

Кто-нибудь знает, как он аутентифицирует SMB, если в AD-домене напрямую пароли н, Аноним (-), 21:22 , 08-Янв-15, (4) //

Возможно задействует smbclient аналогично файловым менеджерам, не , Андрей (??), 21:32 , 08-Янв-15, (5) //

Нет, вроде за собой ничего не тянет Да и смысл ведь в том, что можно будет на л, Mihail Zenkov (ok), 22:58 , 08-Янв-15, (8) //

bloatware полноценность , Аноним (-), 20:43 , 10-Янв-15, (60)

Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS, Аноним (-), 06:44 , 09-Янв-15, (24)

ждем когда поддержка торрент появится , cmp (ok), 23:06 , 08-Янв-15, (9) +4 //

прикололся там ща везде вроде aria2 рулит хотя я предпочитаю wget сделаем и, Аноним (-), 23:53 , 08-Янв-15, (11) –3 //

с разморозкой Ваш КО , pxel (?), 00:21 , 09-Янв-15, (13)
И как, много торрентов wget ом удалось скачать И да, вы знаете, торрент умеет, Аноним (-), 00:21 , 09-Янв-15, (14)
Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel, Mihail Zenkov (ok), 01:13 , 09-Янв-15, (16) //

теперь будем все дружно делать библиотеки и потом морды к ним типа давайте сдел, Аноним (-), 02:50 , 09-Янв-15, (17) –2

всякие жабы и миNETы практически так и устроены, Аноним (-), 03:17 , 09-Янв-15, (18)
Сделать можно очень по-разному Можно хорошо примеры я уже привел , можно не оч, Mihail Zenkov (ok), 03:22 , 09-Янв-15, (19)
Еще как хороший пример вспомнился ffmpeg Или вы его предлагаете распилить на 20, Mihail Zenkov (ok), 03:28 , 09-Янв-15, (20)

del, Mihail Zenkov (ok), 03:31 , 09-Янв-15, (21)
конкретно тут я бы сказал что есть smbclient ffmpeg согласен распиливать не н, Аноним (-), 04:16 , 09-Янв-15, (22)

Но зачем тянуть еще какой-то libsmbclient и кучу его зависимостей libcap2 , lib, Аноним (-), 15:29 , 09-Янв-15, (38)

Подобные исключения наглядно подтверждают некорректность правила Иными словами, , Аноним (-), 14:53 , 09-Янв-15, (35) +4

На практике важна правильная постановка задачи проекта kernel и busybox эти д, Mihail Zenkov (ok), 17:23 , 09-Янв-15, (41)

Противоречите сами себе Например, тот же systemd прекрасно подпадает под определ, Аноним (-), 20:18 , 09-Янв-15, (43) +3

которая тянет за собой d-bus, udev и прочее, но не обеспечивает нормальную работ, Mihail Zenkov (ok), 21:50 , 09-Янв-15, (45) +1

Не тянет, а включает в себя kdbus в основном в ядре, но для его работы нужна от, Аноним (-), 18:07 , 10-Янв-15, (49) +2

Почему все остальные системы инициализации могут прекрасно обходиться без хаков , Mihail Zenkov (ok), 20:09 , 10-Янв-15, (55) +1

Не systemd требует хаков в ядре, а развитие ядра требует systemd К тому же, syst, Аноним (-), 20:28 , 10-Янв-15, (58)

Уже Последние лет пять на busybox без udev dbus etc Нет, неприменимо - в яд, Mihail Zenkov (ok), 20:58 , 10-Янв-15, (61)

Я уже не говорю о том, что Qt - практически единственный вариант для безгеморног, Аноним (-), 20:21 , 09-Янв-15, (44)

Qt - это попытка создать нормальную стандартную библиотеку для c Лучше на дан, Mihail Zenkov (ok), 21:55 , 09-Янв-15, (46)

Нет, это всего лишь означает, что в ярлыке bloatware нет ничего плохого Бесс, Аноним (-), 18:22 , 10-Янв-15, (50)

Проблема bloatware - чрезмерное потребление ресурсов и отсутствие гибкости Боль, Mihail Zenkov (ok), 20:25 , 10-Янв-15, (57)

Разве что места на диске Потреблять _много_ памяти - дурной тон даже для комбай, Аноним (-), 20:40 , 10-Янв-15, (59) –1

Боюсь, что hello world на qt, сожрет больше памяти, чем ядро со всеми драйверами, Mihail Zenkov (ok), 21:23 , 10-Янв-15, (62)

Ухаха, я знаю там то ли какой-то браузерный компонент жаваскрипт движок вроде , электронщег (?), 20:32 , 13-Янв-15, (64)

Да верно - его тянет за собой webkit Но не как опцию, а как обязательную зависи, Mihail Zenkov (ok), 00:45 , 14-Янв-15, (65)

Зуб даю, в тот раз удалось без проблем отпилить Запомнил это потому, что паралл, электронщег (?), 01:53 , 14-Янв-15, (66)

А webkit при этом точно собрался usr libQtWebKit so Собирал qt-5 2 0 вручну, Mihail Zenkov (ok), 03:28 , 14-Янв-15, (67)

Я даже не знаю, что бы делал без libcurl весь последний год на работе , sergey_klay (ok), 05:05 , 09-Янв-15, (23) //

Ах это ты SMB прикрутил Лучше бы работал, честное слово , Ктото там (?), 14:53 , 09-Янв-15, (36) //

Не нравится - будь мужиком, сделай форк curl без SMB , Аноним (-), 20:08 , 10-Янв-15, (54)

Для SMB используется libsmbclient или свой велосипед , Аноним (-), 08:46 , 09-Янв-15, (25) //

Судя по confgiure ac, никаких libsmbclient оно не использует Значит, свой , Аноним (-), 16:12 , 09-Янв-15, (39)

configure Configured to build curl libcurl curl version 7 40 0 Host set, anonimous (?), 09:57 , 09-Янв-15, (26) //

До настоящих мастеров им еще далеко systemd 218 libcryptsetup , Аноним (-), 14:56 , 09-Янв-15, (37) //

это из федоры , Аноним (-), 16:34 , 09-Янв-15, (40) //

Это из CI одного хостинга , Аноним (-), 20:13 , 09-Янв-15, (42)

куды написать чтобы приделали pop3, imap и nfs , Аноним (-), 10:03 , 09-Янв-15, (27) //

pop3 и imap уже Насчёт nfs пишите в спортлото , www2 (ok), 11:38 , 09-Янв-15, (30) //

Так вот кто стоит за разработкой curl , Аноним (-), 20:07 , 10-Янв-15, (53) –1

OMG мои мольбы вообще-то это было скорее тихое нытьё, ну да не важно наконец-, Нанобот (ok), 10:18 , 09-Янв-15, (28) –1

Сообщения [Сортировка по времени | RSS]

16. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 01:13

> идеология юникс же вроде одной задаче
> одна программа)0 причем маленькая программа, а они из линуха вторую винду
> сделать хотят))
Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel. И curl тоже - можно отключить все не нужное и получить очень компактный вариант. А если учесть, что curl - это в первую очередь библиотека для работы с разнообразными сетевыми протоколами, то подобный подход более чем оправдан.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

17. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" –2 +/–

Сообщение от Аноним (-), 09-Янв-15, 02:50

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

Ответить | Правка | Наверх | Cообщить модератору

18. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Аноним (-), 09-Янв-15, 03:17

> теперь будем все дружно делать библиотеки и потом морды к ним? типа
> давайте сделаем одну чтоб описывала все что можно сделать алгоритмически ))
> и скажем вот вам 1 библиотека на1,5 гига а вы ребята
> теперь делайте морды как хотите, но чтоб только маленькие)) это ж
> юникс. нет я понимаю что они хотят расширить возможности программы, но
> зачем пихать в неё то что уже имеется.
всякие жабы и миNETы практически так и устроены

Ответить | Правка | Наверх | Cообщить модератору

19. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 03:22

Сделать можно очень по-разному. Можно хорошо (примеры я уже привел), можно не очень (Qt).
Что касается конкретно curl: любой протокол можно отключить (на стадии компиляции), реализация каждого протокола от 5KB до 200KB, smb - 34KB. При этом мы получаем унифицированный API (сходный для всех протоколов) и мультиплатформенность. Для сравнения - samba (весь исходник) - 115MB. Вот это точно unix way :)

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

20. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 03:28

Еще как хороший пример вспомнился ffmpeg. Или вы его предлагаете распилить на 200 пакетов и в каждом свой API, то-то разработчики плееров обрадуются :)

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

21. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 03:31

del

Ответить | Правка | Наверх | Cообщить модератору

22. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Аноним (-), 09-Янв-15, 04:16

конкретно тут я бы сказал что есть smbclient)) ffmpeg  согласен распиливать не надо.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

38. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Аноним (-), 09-Янв-15, 15:29

> конкретно тут я бы сказал что есть smbclient))
Но зачем тянуть еще какой-то libsmbclient и кучу его зависимостей (libcap2 , libcomerr2, libgssapi-krb5, libk5crypto3, libkrb5, libldap, libtalloc2, libtdb1, libwbclient0, zlib1g), если необходимый функционал можно просто включить в libcurl?
> ffmpeg  согласен распиливать не надо.
Да ничего не надо распиливать. Комбайны практически всегда удобнее, чем нагромождение "модульных" костылей, которое в итоге превращается в такой же комбайн, но хрупкий и переусложненный из-за кучи скриптового "клея" и лени разработчика (ему лень писать нормальный код в своих скриптах, и уж тем более лень документировать что-то).

Ответить | Правка | Наверх | Cообщить модератору

35. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +4 +/–

Сообщение от Аноним (-), 09-Янв-15, 14:53

> Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel.
Подобные исключения наглядно подтверждают некорректность правила.
Иными словами, в теории рулят маленькие программки, а на практике - жирные комбайны.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

41. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 17:23

>> Да, но у любого правила есть исключения, и порой очень удачные - 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 длится во многих пакетах дольше, чем сама сборка), пакеты ругаются друг на друга из-за не подходящих версий, нужно искать подходящие версии.

Ответить | Правка | Наверх | Cообщить модератору

43. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +3 +/–

Сообщение от Аноним (-), 09-Янв-15, 20:18

Противоречите сами себе.
Например, тот же systemd прекрасно подпадает под определение kernel/busybox - обеспечивает минимальную полноценную систему, промежуточный уровень между ядром и UI (внезапно, такой уровень есть). init, системный журнал, DNS, синхронизация времени, учет пользовательских сеансов и т.д., с возможностью опционального включения тех или иных модулей. Тем не менее, вы относите его к классу "антипримеров".
Опять же "компоненты слабо связаны - могут быть использованы друг без друга или заменены альтернативными проектами/библиотеками" - попробуйте заменить модуль ядра Linux на альтернативную реализацию из ядра FreeBSD, используя только опции сборки, скриптовый клей и прочие unix-way инструменты, без "редактирования сорцов в стиле системд". Слабо?

Ответить | Правка | Наверх | Cообщить модератору

45. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +1 +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 21:50

> Например, тот же systemd прекрасно подпадает под определение kernel/busybox -
> обеспечивает минимальную полноценную систему,
которая тянет за собой d-bus, udev и прочее, но не обеспечивает нормальную работу пользователя без *nix utils
> промежуточный уровень между ядром и UI (внезапно, такой
> уровень есть).
для которого вполне достаточно возможностей busybox
> init, системный журнал, DNS, синхронизация времени, учет пользовательских
> сеансов и т.д., с возможностью опционального включения тех или иных модулей.
> Тем не менее, вы относите его к классу "антипримеров".
Потому что нельзя использовать logind без того чтобы не притянуть остальной systemd/d-bus/etc.
> Опять же "компоненты слабо связаны - могут быть использованы друг без друга
> или заменены альтернативными проектами/библиотеками" - попробуйте заменить модуль ядра
> Linux на альтернативную реализацию из ядра FreeBSD,
Некорректно поставлено условие. В ядре можно использовать модули по-раздельности (слабо зависят друг от друга) и можно подгружать альтернативные, не входящие в ядро. Можно заменить почти все части ядра - звуковую подсистему/планировщики/etc.

Ответить | Правка | Наверх | Cообщить модератору

49. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +2 +/–

Сообщение от Аноним (-), 10-Янв-15, 18:07

> которая тянет за собой 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.
Не написав и не изменив ни одной строчки сишного кода, да? :)

Ответить | Правка | Наверх | Cообщить модератору

55. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +1 +/–

Сообщение от Mihail Zenkov (ok), 10-Янв-15, 20:09

> Не тянет, а включает в себя. kdbus в основном в ядре, но
> для его работы нужна ответная часть в юзерспейсе, реализованная в systemd.
Почему все остальные системы инициализации могут прекрасно обходиться без хаков в ядре?
> Помимо обеспечения нормальной работы пользователя, нужно обеспечивать еще и нормальную
> работу программ. Неожиданно, да?
Программы вообще ничего о системе инициализации знать не должны. Если система инициализации подготовила все для нормальной работы пользователя, то программы должны нормально работать, иначе как пользователь сможет нормально работать?

> init, IPC, системный журнал, сеть и прочее - не являются прямо необходимыми
> для работы пользователя. Ему достаточно init=/bin/sh. Но почему-то так работать никто
> не хочет.
> В подавляющем большинстве случаев - нет.
Ну и чего не может busybox? И почему все раньше работало, а с приходом systemd оказалось что не могло оно работать?
> В подавляющем большинстве случаев - нет.
Я уже писал длинный пост о systemd vs init, с разбором конкретных реальных ситуаций:
https://www.opennet.ru/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 или еще какой.

Ответить | Правка | Наверх | Cообщить модератору

58. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Аноним (-), 10-Янв-15, 20:28

> Почему все остальные системы инициализации могут прекрасно обходиться без хаков в ядре?
Не systemd требует хаков в ядре, а развитие ядра требует systemd.
К тому же, systemd - это не только система инициализации. Это base layer of linux userspace.
> Программы вообще ничего о системе инициализации знать не должны.
Спорно. Опыт классических UNIX-систем (Mac OS X и Solaris) показывает, что тесная интеграция инита и демонов дает определенные плюсы (сокет-активация, удобный мониторинг, перезапуск без закрытия соединений и т.д.).
> Ну и чего не может busybox? И почему все раньше работало, а с приходом systemd оказалось что не могло оно работать?
Что не может телега? Почему раньше все работало, а с приходом автомобилей оказалось, что не могло оно работать?
systemd более удобен и технологичен, только и всего. Попробуйте построить десктопный дистрибутив на основе busybox - проникнетесь ;)
> Я уже писал длинный пост о systemd vs init, с разбором конкретных реальных ситуаций:
> https://www.opennet.ru/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 или еще какой.
Поздравляю, хот что-то вы можете заменить в своей "неблоатварной" системе :)

Ответить | Правка | Наверх | Cообщить модератору

61. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 10-Янв-15, 20:58

> Попробуйте построить десктопный дистрибутив
> на основе busybox - проникнетесь ;)
Уже :) Последние лет пять на busybox (без udev/dbus/etc).
> Все это можно применить и к ядру Linux.
Нет, неприменимо - в ядре есть oss и alsa, куча планировщиков, ФС. Выбрать можно, что угодно - на остальные подсистемы это не повлияет. Тем более что разработку можно вести вне ядра и подгружать/заменять модули.
> весьма демагогично. Попробуйте заменить в Gentoo OpenRC на SysVinit. Подсказка: OpenRC
> использует свой формат скриптов, несовместимых с SysV, поэтому вам придется переписать
> скрипты для всех демонов.
Скрипты - неотъемлемая часть системы инициализации, это ее система конфигурации. Из системных компонентов обычно заменяют только init, остальное используют то, что есть в системе. А не пишут свой логер/dns сервер и т.д, которые завязан на systemd так, что не могут работать в других системах инициализации.
>> Посмотрите пример с сеткой
> Где?
Нету ссылку дал, вот правильная:
https://www.opennet.ru/openforum/vsluhforumID3/100356.html#434

>> Тогда почему я могу использовать только mdev, заменив весь остальной busybox другими
>> *nix utils (хоть gnu, хоть bsd).
> Потому что в наборе утилит командной строки интеграция не такая сильная, как
> в модулях ядра или базовой системы.
Модули ядра слабо зависят друг от друга. Udev может быть заменен на mdev. И как не странно все работает, за исключением systemd ;)
> Окей, дайте мне модуль, заменяющий netfilter. Ядро 3.2.63, есличо.
Не для всех модулей есть аналоги. Но при необходимости их можно написать.
> Поздравляю, хот что-то вы можете заменить в своей "неблоатварной" системе :)
Заменить можно практически все. Было бы желание и поменьше Поттерингов, продвигающих единственно правильное решение :)

Ответить | Правка | Наверх | Cообщить модератору

44. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Аноним (-), 09-Янв-15, 20:21

Я уже не говорю о том, что Qt - практически единственный вариант для безгеморного создания кроссплатформенных приложений, причем не только графических. Массовый свалинг проектов с Gtk на Qt полностью подтверждает этот тезис.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

46. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 09-Янв-15, 21:55

Qt - это попытка создать нормальную стандартную библиотеку для c++. Лучше на данный момент ничего нет. Но это не значит, что Qt не bloatware и все от нее в восторге.
Путь развития gtk3/gnome3 многих не устраивает, вот и бегут, кто назад на gtk2, кто на qt.

Ответить | Правка | Наверх | Cообщить модератору

50. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Аноним (-), 10-Янв-15, 18:22

> Qt - это попытка создать нормальную стандартную библиотеку для c++. Лучше на данный момент ничего нет. Но это не значит, что Qt не bloatware и все от нее в восторге.
Нет, это всего лишь означает, что в ярлыке "bloatware" нет ничего плохого :)
Бессмысленно приводить блоатварность в качестве недостатка, потому что во всех ваших примерах ее реальные плюсы (удобство - вся необходимая функциональность под рукой) перевешивают мнимые минусы (отсутствие "минимализма", который вообще-то мотивирован соображениями скорее эстетическими, нежели практическими).

Ответить | Правка | Наверх | Cообщить модератору

57. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 10-Янв-15, 20:25

> Нет, это всего лишь означает, что в ярлыке "bloatware" нет ничего плохого
> :)
> Бессмысленно приводить блоатварность в качестве недостатка, потому что во всех ваших примерах
> ее реальные плюсы (удобство - вся необходимая функциональность под рукой) перевешивают
> мнимые минусы (отсутствие "минимализма", который вообще-то мотивирован соображениями
> скорее эстетическими, нежели практическими).
Проблема bloatware - чрезмерное потребление ресурсов и отсутствие гибкости. Большая кодовая база ведет к большому количеству багов. Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование. Не говоря о том, что сборка Qt и подобных, дело отнюдь не десяти минут. Если возникнет необходимость портировать на новую платформу, то проще переписать приложение на другой toolkit, чем портировать Qt.

Ответить | Правка | Наверх | Cообщить модератору

59. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" –1 +/–

Сообщение от Аноним (-), 10-Янв-15, 20:40

> Проблема bloatware - чрезмерное потребление ресурсов
Разве что места на диске. Потреблять _много_ памяти - дурной тон даже для комбайнов.
> и отсутствие гибкости.
Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых задач, чем требовать возни с компоновкой модулей при любом раскладе.
> Большая кодовая база ведет к большому количеству багов.
Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший сумарный объем кода - в комбайне, в котором совместное использование всяких общих функций проще, или в десятке-другом независимых проектов?
> Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование.
Спорно.
Если взять комбайн и разбить его на сотню "независимых" проектов - все равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка за миску риса, которой на все пофиг), и тестировать конечный продукт, поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда может аукнуться в другом.
> Если возникнет необходимость портировать на новую платформу, то проще переписать приложение на другой toolkit, чем портировать Qt.
Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3, который пилят в основном под Linux.

Ответить | Правка | Наверх | Cообщить модератору

62. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 10-Янв-15, 21:23

> Разве что места на диске. Потреблять _много_ памяти - дурной тон даже
> для комбайнов.
Боюсь, что hello world на qt, сожрет больше памяти, чем ядро со всеми драйверами для дескотпа ;)
> Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых
> задач, чем требовать возни с компоновкой модулей при любом раскладе.
Верно, но компоновать нужно по задаче - нужны кодаки - возьму ffmpeg. Нужны базовые сетевые протоколы - возьму curl. И т.д. Нет смысла компоновать слабо связанные задачи в одну библиотеку.
> Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший
> сумарный объем кода - в комбайне, в котором совместное использование всяких
> общих функций проще, или в десятке-другом независимых проектов?
Пример: нужен простой видео плеер с поддержкой http и выводом через opengl.
Вариант 1: ffmepg+curl+glfw.
Вариант 2: Qt(+куча зависимостей) + ffmpeg.
Где меньше сумарный объем кода?
>> Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование.
> Спорно.
> Если взять комбайн и разбить его на сотню "независимых" проектов - все
> равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка
> за миску риса, которой на все пофиг), и тестировать конечный продукт,
> поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда
> может аукнуться в другом.
Если я правлю баг в curl, как это отразится на ffmpeg?
> Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3,
> который пилят в основном под Linux.
Выбирают из-за того что он уже портирован. Портировать такой объем кода на новую платформу ради одной программы никто в здравом уме не будет.

Ответить | Правка | Наверх | Cообщить модератору

64. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от электронщег (?), 13-Янв-15, 20:32

>> <offtop>Вопрос на уроке информатики: Дети, кто знает, зачем Qt тянет за собой Ruby?</offtop>
Ухаха, я знаю: там то ли какой-то браузерный компонент (жаваскрипт движок вроде), то ли документация к нему требуют в системе наличия этого самого руби для сборки Qt из исходников. Выяснил это, когда пытался собрать свежие Qt на моей уютной генте. И ужаснулся, когда в зависимостях увидел ЭТО. Тогда всё разрешилось клонированием ебилда в локальный репозиторий и удалением оттуда одной строки, обьявляющей руби как зависимость. На удивление, всё собралось.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

65. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 14-Янв-15, 00:45

Да верно - его тянет за собой webkit. Но не как опцию, а как обязательную зависимость. Там действительно часть движка на ruby написана, так что так просто не отпилишь.

Ответить | Правка | Наверх | Cообщить модератору

66. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от электронщег (?), 14-Янв-15, 01:53

> Да верно - его тянет за собой webkit. Но не как опцию,
> а как обязательную зависимость. Там действительно часть движка на ruby написана,
> так что так просто не отпилишь.
Зуб даю, в тот раз удалось без проблем отпилить. Запомнил это потому, что параллельно с обновлением своей системы подготавливал специализированный LiveCD на основе stage3, который еле влепил в 700мб (да, кое где ещё пользуются CD-R, не спрашивайте). Гарантирую, с руби на борту этого бы не удалось. Вроде версия Qt была 5.2. Возможно, спасла магия USE-флагов, благодаря которой не стали собираться зависимые от руби части вебкита.

Ответить | Правка | Наверх | Cообщить модератору

67. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS" +/–

Сообщение от Mihail Zenkov (ok), 14-Янв-15, 03:28

А webkit при этом точно собрался (/usr/libQtWebKit.so.*)?
Собирал qt-5.2.0 вручную. Единственный возможный вариант была сборка без webkit. Может в gentoo есть специальные патчи для избавления webkit от ruby? Если так, то киньте ссылку.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	16. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 01:13
	> идеология юникс же вроде одной задаче > одна программа)0 причем маленькая программа, а они из линуха вторую винду > сделать хотят)) Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel. И curl тоже - можно отключить все не нужное и получить очень компактный вариант. А если учесть, что curl - это в первую очередь библиотека для работы с разнообразными сетевыми протоколами, то подобный подход более чем оправдан.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	17. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	–2 +/–
	Сообщение от Аноним (-), 09-Янв-15, 02:50
	теперь будем все дружно делать библиотеки и потом морды к ним? типа давайте сделаем одну чтоб описывала все что можно сделать алгоритмически )) и скажем вот вам 1 библиотека на1,5 гига а вы ребята теперь делайте морды как хотите, но чтоб только маленькие)) это ж юникс. нет я понимаю что они хотят расширить возможности программы, но зачем пихать в неё то что уже имеется.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Аноним (-), 09-Янв-15, 03:17
	> теперь будем все дружно делать библиотеки и потом морды к ним? типа > давайте сделаем одну чтоб описывала все что можно сделать алгоритмически )) > и скажем вот вам 1 библиотека на1,5 гига а вы ребята > теперь делайте морды как хотите, но чтоб только маленькие)) это ж > юникс. нет я понимаю что они хотят расширить возможности программы, но > зачем пихать в неё то что уже имеется. всякие жабы и миNETы практически так и устроены
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 03:22
	Сделать можно очень по-разному. Можно хорошо (примеры я уже привел), можно не очень (Qt). Что касается конкретно curl: любой протокол можно отключить (на стадии компиляции), реализация каждого протокола от 5KB до 200KB, smb - 34KB. При этом мы получаем унифицированный API (сходный для всех протоколов) и мультиплатформенность. Для сравнения - samba (весь исходник) - 115MB. Вот это точно unix way :)
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	20. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 03:28
	Еще как хороший пример вспомнился ffmpeg. Или вы его предлагаете распилить на 200 пакетов и в каждом свой API, то-то разработчики плееров обрадуются :)
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	21. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 03:31
	del
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Аноним (-), 09-Янв-15, 04:16
	конкретно тут я бы сказал что есть smbclient)) ffmpeg согласен распиливать не надо.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	38. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Аноним (-), 09-Янв-15, 15:29
	> конкретно тут я бы сказал что есть smbclient)) Но зачем тянуть еще какой-то libsmbclient и кучу его зависимостей (libcap2 , libcomerr2, libgssapi-krb5, libk5crypto3, libkrb5, libldap, libtalloc2, libtdb1, libwbclient0, zlib1g), если необходимый функционал можно просто включить в libcurl? > ffmpeg согласен распиливать не надо. Да ничего не надо распиливать. Комбайны практически всегда удобнее, чем нагромождение "модульных" костылей, которое в итоге превращается в такой же комбайн, но хрупкий и переусложненный из-за кучи скриптового "клея" и лени разработчика (ему лень писать нормальный код в своих скриптах, и уж тем более лень документировать что-то).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+4 +/–
	Сообщение от Аноним (-), 09-Янв-15, 14:53
	> Да, но у любого правила есть исключения, и порой очень удачные - busybox, kernel. Подобные исключения наглядно подтверждают некорректность правила. Иными словами, в теории рулят маленькие программки, а на практике - жирные комбайны.
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	41. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 17:23
	>> Да, но у любого правила есть исключения, и порой очень удачные - 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 длится во многих пакетах дольше, чем сама сборка), пакеты ругаются друг на друга из-за не подходящих версий, нужно искать подходящие версии.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+3 +/–
	Сообщение от Аноним (-), 09-Янв-15, 20:18
	Противоречите сами себе. Например, тот же systemd прекрасно подпадает под определение kernel/busybox - обеспечивает минимальную полноценную систему, промежуточный уровень между ядром и UI (внезапно, такой уровень есть). init, системный журнал, DNS, синхронизация времени, учет пользовательских сеансов и т.д., с возможностью опционального включения тех или иных модулей. Тем не менее, вы относите его к классу "антипримеров". Опять же "компоненты слабо связаны - могут быть использованы друг без друга или заменены альтернативными проектами/библиотеками" - попробуйте заменить модуль ядра Linux на альтернативную реализацию из ядра FreeBSD, используя только опции сборки, скриптовый клей и прочие unix-way инструменты, без "редактирования сорцов в стиле системд". Слабо?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+1 +/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 21:50
	> Например, тот же systemd прекрасно подпадает под определение kernel/busybox - > обеспечивает минимальную полноценную систему, которая тянет за собой d-bus, udev и прочее, но не обеспечивает нормальную работу пользователя без *nix utils > промежуточный уровень между ядром и UI (внезапно, такой > уровень есть). для которого вполне достаточно возможностей busybox > init, системный журнал, DNS, синхронизация времени, учет пользовательских > сеансов и т.д., с возможностью опционального включения тех или иных модулей. > Тем не менее, вы относите его к классу "антипримеров". Потому что нельзя использовать logind без того чтобы не притянуть остальной systemd/d-bus/etc. > Опять же "компоненты слабо связаны - могут быть использованы друг без друга > или заменены альтернативными проектами/библиотеками" - попробуйте заменить модуль ядра > Linux на альтернативную реализацию из ядра FreeBSD, Некорректно поставлено условие. В ядре можно использовать модули по-раздельности (слабо зависят друг от друга) и можно подгружать альтернативные, не входящие в ядро. Можно заменить почти все части ядра - звуковую подсистему/планировщики/etc.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+2 +/–
	Сообщение от Аноним (-), 10-Янв-15, 18:07
	> которая тянет за собой 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. Не написав и не изменив ни одной строчки сишного кода, да? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+1 +/–
	Сообщение от Mihail Zenkov (ok), 10-Янв-15, 20:09
	> Не тянет, а включает в себя. kdbus в основном в ядре, но > для его работы нужна ответная часть в юзерспейсе, реализованная в systemd. Почему все остальные системы инициализации могут прекрасно обходиться без хаков в ядре? > Помимо обеспечения нормальной работы пользователя, нужно обеспечивать еще и нормальную > работу программ. Неожиданно, да? Программы вообще ничего о системе инициализации знать не должны. Если система инициализации подготовила все для нормальной работы пользователя, то программы должны нормально работать, иначе как пользователь сможет нормально работать? > init, IPC, системный журнал, сеть и прочее - не являются прямо необходимыми > для работы пользователя. Ему достаточно init=/bin/sh. Но почему-то так работать никто > не хочет. > В подавляющем большинстве случаев - нет. Ну и чего не может busybox? И почему все раньше работало, а с приходом systemd оказалось что не могло оно работать? > В подавляющем большинстве случаев - нет. Я уже писал длинный пост о systemd vs init, с разбором конкретных реальных ситуаций: https://www.opennet.ru/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 или еще какой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Аноним (-), 10-Янв-15, 20:28
	> Почему все остальные системы инициализации могут прекрасно обходиться без хаков в ядре? Не systemd требует хаков в ядре, а развитие ядра требует systemd. К тому же, systemd - это не только система инициализации. Это base layer of linux userspace. > Программы вообще ничего о системе инициализации знать не должны. Спорно. Опыт классических UNIX-систем (Mac OS X и Solaris) показывает, что тесная интеграция инита и демонов дает определенные плюсы (сокет-активация, удобный мониторинг, перезапуск без закрытия соединений и т.д.). > Ну и чего не может busybox? И почему все раньше работало, а с приходом systemd оказалось что не могло оно работать? Что не может телега? Почему раньше все работало, а с приходом автомобилей оказалось, что не могло оно работать? systemd более удобен и технологичен, только и всего. Попробуйте построить десктопный дистрибутив на основе busybox - проникнетесь ;) > Я уже писал длинный пост о systemd vs init, с разбором конкретных реальных ситуаций: > https://www.opennet.ru/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 или еще какой. Поздравляю, хот что-то вы можете заменить в своей "неблоатварной" системе :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 10-Янв-15, 20:58
	> Попробуйте построить десктопный дистрибутив > на основе busybox - проникнетесь ;) Уже :) Последние лет пять на busybox (без udev/dbus/etc). > Все это можно применить и к ядру Linux. Нет, неприменимо - в ядре есть oss и alsa, куча планировщиков, ФС. Выбрать можно, что угодно - на остальные подсистемы это не повлияет. Тем более что разработку можно вести вне ядра и подгружать/заменять модули. > весьма демагогично. Попробуйте заменить в Gentoo OpenRC на SysVinit. Подсказка: OpenRC > использует свой формат скриптов, несовместимых с SysV, поэтому вам придется переписать > скрипты для всех демонов. Скрипты - неотъемлемая часть системы инициализации, это ее система конфигурации. Из системных компонентов обычно заменяют только init, остальное используют то, что есть в системе. А не пишут свой логер/dns сервер и т.д, которые завязан на systemd так, что не могут работать в других системах инициализации. >> Посмотрите пример с сеткой > Где? Нету ссылку дал, вот правильная: https://www.opennet.ru/openforum/vsluhforumID3/100356.html#434 >> Тогда почему я могу использовать только mdev, заменив весь остальной busybox другими >> *nix utils (хоть gnu, хоть bsd). > Потому что в наборе утилит командной строки интеграция не такая сильная, как > в модулях ядра или базовой системы. Модули ядра слабо зависят друг от друга. Udev может быть заменен на mdev. И как не странно все работает, за исключением systemd ;) > Окей, дайте мне модуль, заменяющий netfilter. Ядро 3.2.63, есличо. Не для всех модулей есть аналоги. Но при необходимости их можно написать. > Поздравляю, хот что-то вы можете заменить в своей "неблоатварной" системе :) Заменить можно практически все. Было бы желание и поменьше Поттерингов, продвигающих единственно правильное решение :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Аноним (-), 09-Янв-15, 20:21
	Я уже не говорю о том, что Qt - практически единственный вариант для безгеморного создания кроссплатформенных приложений, причем не только графических. Массовый свалинг проектов с Gtk на Qt полностью подтверждает этот тезис.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	46. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 09-Янв-15, 21:55
	Qt - это попытка создать нормальную стандартную библиотеку для c++. Лучше на данный момент ничего нет. Но это не значит, что Qt не bloatware и все от нее в восторге. Путь развития gtk3/gnome3 многих не устраивает, вот и бегут, кто назад на gtk2, кто на qt.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Аноним (-), 10-Янв-15, 18:22
	> Qt - это попытка создать нормальную стандартную библиотеку для c++. Лучше на данный момент ничего нет. Но это не значит, что Qt не bloatware и все от нее в восторге. Нет, это всего лишь означает, что в ярлыке "bloatware" нет ничего плохого :) Бессмысленно приводить блоатварность в качестве недостатка, потому что во всех ваших примерах ее реальные плюсы (удобство - вся необходимая функциональность под рукой) перевешивают мнимые минусы (отсутствие "минимализма", который вообще-то мотивирован соображениями скорее эстетическими, нежели практическими).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 10-Янв-15, 20:25
	> Нет, это всего лишь означает, что в ярлыке "bloatware" нет ничего плохого > :) > Бессмысленно приводить блоатварность в качестве недостатка, потому что во всех ваших примерах > ее реальные плюсы (удобство - вся необходимая функциональность под рукой) перевешивают > мнимые минусы (отсутствие "минимализма", который вообще-то мотивирован соображениями > скорее эстетическими, нежели практическими). Проблема bloatware - чрезмерное потребление ресурсов и отсутствие гибкости. Большая кодовая база ведет к большому количеству багов. Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование. Не говоря о том, что сборка Qt и подобных, дело отнюдь не десяти минут. Если возникнет необходимость портировать на новую платформу, то проще переписать приложение на другой toolkit, чем портировать Qt.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	–1 +/–
	Сообщение от Аноним (-), 10-Янв-15, 20:40
	> Проблема bloatware - чрезмерное потребление ресурсов Разве что места на диске. Потреблять _много_ памяти - дурной тон даже для комбайнов. > и отсутствие гибкости. Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых задач, чем требовать возни с компоновкой модулей при любом раскладе. > Большая кодовая база ведет к большому количеству багов. Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший сумарный объем кода - в комбайне, в котором совместное использование всяких общих функций проще, или в десятке-другом независимых проектов? > Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование. Спорно. Если взять комбайн и разбить его на сотню "независимых" проектов - все равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка за миску риса, которой на все пофиг), и тестировать конечный продукт, поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда может аукнуться в другом. > Если возникнет необходимость портировать на новую платформу, то проще переписать приложение на другой toolkit, чем портировать Qt. Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3, который пилят в основном под Linux.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 10-Янв-15, 21:23
	> Разве что места на диске. Потреблять _много_ памяти - дурной тон даже > для комбайнов. Боюсь, что hello world на qt, сожрет больше памяти, чем ядро со всеми драйверами для дескотпа ;) > Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых > задач, чем требовать возни с компоновкой модулей при любом раскладе. Верно, но компоновать нужно по задаче - нужны кодаки - возьму ffmpeg. Нужны базовые сетевые протоколы - возьму curl. И т.д. Нет смысла компоновать слабо связанные задачи в одну библиотеку. > Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший > сумарный объем кода - в комбайне, в котором совместное использование всяких > общих функций проще, или в десятке-другом независимых проектов? Пример: нужен простой видео плеер с поддержкой http и выводом через opengl. Вариант 1: ffmepg+curl+glfw. Вариант 2: Qt(+куча зависимостей) + ffmpeg. Где меньше сумарный объем кода? >> Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование. > Спорно. > Если взять комбайн и разбить его на сотню "независимых" проектов - все > равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка > за миску риса, которой на все пофиг), и тестировать конечный продукт, > поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда > может аукнуться в другом. Если я правлю баг в curl, как это отразится на ffmpeg? > Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3, > который пилят в основном под Linux. Выбирают из-за того что он уже портирован. Портировать такой объем кода на новую платформу ради одной программы никто в здравом уме не будет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от электронщег (?), 13-Янв-15, 20:32
	>> <offtop>Вопрос на уроке информатики: Дети, кто знает, зачем Qt тянет за собой Ruby?</offtop> Ухаха, я знаю: там то ли какой-то браузерный компонент (жаваскрипт движок вроде), то ли документация к нему требуют в системе наличия этого самого руби для сборки Qt из исходников. Выяснил это, когда пытался собрать свежие Qt на моей уютной генте. И ужаснулся, когда в зависимостях увидел ЭТО. Тогда всё разрешилось клонированием ебилда в локальный репозиторий и удалением оттуда одной строки, обьявляющей руби как зависимость. На удивление, всё собралось.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	65. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 14-Янв-15, 00:45
	Да верно - его тянет за собой webkit. Но не как опцию, а как обязательную зависимость. Там действительно часть движка на ruby написана, так что так просто не отпилишь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от электронщег (?), 14-Янв-15, 01:53
	> Да верно - его тянет за собой webkit. Но не как опцию, > а как обязательную зависимость. Там действительно часть движка на ruby написана, > так что так просто не отпилишь. Зуб даю, в тот раз удалось без проблем отпилить. Запомнил это потому, что параллельно с обновлением своей системы подготавливал специализированный LiveCD на основе stage3, который еле влепил в 700мб (да, кое где ещё пользуются CD-R, не спрашивайте). Гарантирую, с руби на борту этого бы не удалось. Вроде версия Qt была 5.2. Возможно, спасла магия USE-флагов, благодаря которой не стали собираться зависимые от руби части вебкита.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Новая версия утилиты cURL 7.40.0 с поддержкой SMB/CIFS"	+/–
	Сообщение от Mihail Zenkov (ok), 14-Янв-15, 03:28
	А webkit при этом точно собрался (/usr/libQtWebKit.so.*)? Собирал qt-5.2.0 вручную. Единственный возможный вариант была сборка без webkit. Может в gentoo есть специальные патчи для избавления webkit от ruby? Если так, то киньте ссылку.
	Ответить \| Правка \| Наверх \| Cообщить модератору