Дистрибутивы Linux столкнулись с проблемой с разрастанием зависимостей у проектов. Если для кода на Python, Perl и Ruby число зависимостей держится в разумных пределах, то в проектах на JavaScript практикуется дробление на очень мелкие библиотеки, часто выполняющие одну простую функцию. Репозиторий NPM уже насчитывает более миллиона пакетов, а типовые приложения связываются с сотнями зависимостей, которые, в свою очередь, имеют свои зависимости, что усложняет сопровождение и распространение традиционных пакетов с JavaScript-приложениями в дистрибутивах Linux...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54402
Выкинуть "программы на Node.js" на мороз, вместе с JS библиотеками.
Кому надо, пусть тащит снаружи.
Ваще не ясно, зачем "это", кому надо и сам пакет соберет. В мейн репы пихать JS ну такоэ
+1. Эта нестабильная масса работает только установкой самого распоследнего, ну вот пусть и ставят всё сами. А то, что от этого зависит, само виновато. Взялся за node.js — страдай.
Это ты сейчас на, свет наш электрон, бочку катить?
Абсолютно так. Выпилить нафиг, и всё. Оставить только сам транслятор и пакетный менеджер для него.
> дробление на очень мелкие библиотеки, часто выполняющие одну простую функциюНо разве это не эталонный юниксвей ?
В эпоху юникса наверно им такое и не снилось, что столько велосипедов амбициозные будут городить, называя это творчеством и развитием. Не надо путать жизнь в компе-коде и жизнь полноценную, не будет и таких сублимаций.
Причем тут "жизнь - не жизнь" ?
Ведь суть тех пакетов в том, что "каждый выполняет одну задачу но делает это хорошо и алгоритм взаимодействия открыт"..
Ничего не напоминает ?
Обычно есть ещё предел разумного. Хорошо когда одна утилита выполняет что то просто одно и хорошо.
Но когда извините пояляются пакет который удаляет все пробелы слева, который зависим от пакета, который удаляет один пробел слева. То как бы ахриненно они это делали это уже за гранью разумного.
Однако смузи слишком сильно меняет этот самый предел разумности.
Но не когда одну и ту же задачу выполняют сотни-тысячи пакетов, потому что форкать - это так прикольно.
> Но не когда одну и ту же задачу выполняют сотни-тысячи пакетов, потому
> что форкать - это так прикольно.Задачи отличаются, отличается апи, отличаются нюансы обработки, отличаются доки.
Да, форкать прикольно.
Тонны юниксвейных DE, WM и проч соврать не дадут, не так ли ?)
Обратите внимание на слово "хорошо". Пример: утилита dd делает лишь одно: копирует с одного файла в другой, но столько ей применений! Вот ЭТО юниксвей а не удаление пробелов отдельной библиотекой.
> Обратите внимание на слово "хорошо". Пример: утилита dd делает лишь одно: копирует
> с одного файла в другой, но столько ей применений! Вот ЭТО
> юниксвей а не удаление пробелов отдельной библиотекой.Но разве та библиотека плохо удаляет пробелы ?
> Но разве та библиотека плохо удаляет пробелы ?В строках с виндовой кодировкой хорошо. Для утф нужна другая.
Так это же юниксвей!
> Так это же юниксвей!Юниксвей содержит слово "хорошо". А тут, очевидно, о "хорошо" говорить нельзя. Так что это виндовсвей - плодить несовместимые библиотеки, делающие одно и то же, но все поразному и все криво.
Ну представьте, если бы dd могда только сохранить образ раздела в файл, но не могла ни читать CD/DVD/USB из /dev/null / /dev/random... и даже не могла бы писать обратно из образа на раздел.
Одну пользовательскую задачу, а не одно бесполезное действие. Представьте, если вместо math.h из стандартной библиотеки, была бы библиотека складывающая 2+2 или библиотека могла складывать только чётные числа и которая зависела от библиотеки складывающей 2+2.
> Одну пользовательскую задачу, а не одно бесполезное действие. Представьте, если вместо
> math.h из стандартной библиотеки, была бы библиотека складывающая 2+2 или библиотека
> могла складывать только чётные числа и которая зависела от библиотеки складывающей
> 2+2.Может ведь так оказаться, что абсолютное большинство конечных разработчиков практически не использует модули, выполняющие одно-единственное действие( сам подобное если и использую, то просто сам необходимый код в проект переношу, поскольку мне нафиг не нужны какие-то допиливания в будущем и абсолютно устраивает нынешняя реализация и не нужны лишние зависимости от нанопакетов ).
Для пользователя/разработчика одна задача - это создание/чтение/запись в ФС / отправка запросов по сети / итп.
Для разработчика модуля работы с сетью одна задача - это парсинг заголовка / тела ответа, формирование заголовка / тела запроса( в которые входят еще куда нетривиальных подзадач )
Для разработчика парсера одна задача - это дробление строки по конкретному алгоритму / приведение данных в приемлемый вид итп
И так далееНа самом деле, в подобном подходе и нынешней простоте создания модулей и пакетов есть очень серьезный плюс - практически полная независимость от разработчика конкретного пакета( самые упоротые вспомнят лифпад или как он там, но проблема конкретно с ним была в возможности владельца пакета с чистой совестью его полностью выпилить из репозитория, что он и сделал и "внезапно" посыпались использующие его модули. Ту возможность давно прикрыли ).
В противоположность этому есть т.н "сообщество" QT, в котором практически все принадлежит и зависит от конкретной конторы, которая занимается разработкой/допиливанием и проч, есть совершенно конкретный огороженный набор компонентов и модулей.. и фактически все в QT будет ровно так как захочет путевая контора вне зависимости от желания или не_желания сторонних разработчиков.
Проблему усугубляют привязки к версиям - ядро может требовать для стабильной работы одной версии зависимости, а драйвер SATA - другой.
А что такое юниксвей? То что в явасцэнаристов это как будто бы каждую функцию языка программирования (ну или его стандартную библиотеку) выделили в отдельный файл что очень тупо.
Создателям unix-way в страшном сне не могло приснится что программы будут писать вот так
var passAll = require('101/pass-all')
var isPositive = require('is-positive')
var isInteger = require('is-integer')module.exports = passAll(isPositive, isInteger)
Это называется бездумная овердекомпозиция и бездумный оверинжиниринг.
Нет
Между лефтпадвеем и юниксвеем огромная разница.
В юниксвее утилита должна выполнять какую-либо простую, но утилитарную функцию.
Лефтпад сам по себе на фиг не нужен.
А между тем, Аноним идёт на рекорд по +
Так они и так качают с гитов напрямую
Всецело поддерживаю!
Я даже и не знал что кто-то додумался npm-ое дерьмо в репы пихать.
Плюсую. Как человек, использующий ноду и npm каждый день, понятия не имею, на кой черт оно в дистрибутиве, и кто в здравом уме будет это использовать.
Если нужна какая-то тула, её можно и скомпилить.
+1. Хороший индикатор безголовости получился, похоже.
> Кому надо, пусть тащит снаружиДа, надо.
В жизни не держал Node.js в системе, хотя работаю с ним на ежедневной основе.Проект -> Личный зверинец проекта -> Все NPM-пакеты проекта
Просто для того, чтобы хоть как-то контролировать состав малвари, поставляемой клиенту.
Проблемы дистров, не использующих систему портов.
Ты хотел сказать "проблемы дистров, не желающих быть совсем уж bleeding edge"?
Fedora хоть и близка к bleeding edge, но остатки адекватности - как видим - сохранили, и понимают, что может случаться при бездумном обновлении всего.
А зачем бездумно обновлять всё? Системная часть стабильна, остальное можно и портами. Как в freebsd.
И юзабельность станет такая же как у фрибзди. С результатом в полтора юзера.
> И юзабельность станет такая же как у фрибзди.Ну да, если низзя разнести системную часть обновлением стороннего ПО, т.е. сделано "не как в венде!", то пука^W юзабельность бедных юзерков страдает! Очень страдает!
То-то в сузе и федоре играются с атомарными обновлениями системы, да всякие EndlessOS
https://www.opennet.me/opennews/art.shtml?num=54060
> Дистрибутив не использует традиционные пакетные менеджеры, вместо которых предлагается минимальная атомарно обновляемая базовая система, работающая в режиме только для чтения и формируемая при помощи инструментария OSTree (системный образ атомарно обновляется из Git-подобного хранилища). Идентичные с Endless OS идеи в последнее время пытаются повторить разработчики Fedora в рамках проекта Silverblue по созданию атомарно обновляемого варианта Fedora Workstation. Инсталлятор и система обновления Endless OS, как и планировалось, теперь используются в GNOME OS.изобретают
> С результатом в полтора юзера.
Ну тогда для вас вендовые подходы к софтоинсталляции будут самыми правильными и верными! Ведь миллионы юзеров венды не могут ошибаться!
Именно так. Для десктопа "вендовые" подходы - самые правильные и верные.
На серверах в основном Linux. На телефонах тоже.А фрибздя и прочее - ныне остаются исключительно у любителей нетрадиционных подходов.
> Именно так. Для десктопа "вендовые" подходы - самые правильные и верные.
> На телефонах тоже.Вот они, современные линуксоиды - топят за венду и вендорлок.
Правда, на телефонах ОСь (котрая совсем не GNU/Linux) обновляется отдельно от установленного софта (а софт, по умолчанию, предполагается устанавливать из адварь-спайвар-помоеек - но когда упоминают эти пункты, ведроид почему-то резко перестает быть "линуксом" и становится "там от линукса только ядро!" - удобно то как!).
> А фрибздя и прочее - ныне остаются исключительно у любителей нетрадиционных подходов.
Но конкретики о "неюзабельности", как обычно, не будет.
Конкретика простая
FreeBSD is used by 0.4% of all the websites whose operating system we know
> Конкретика простая
> FreeBSD is used by 0.4% of all the websites whose operating system we knowКонкретика - это не просто набро^W заявление с приведением чего-то, взятого с потолка и умным видом, но и обоснование, почему одно следует из другого.
Оттуда же:
> Unix is used by 72.5% of all the websites whose operating system we know.
> Unknown 60.3%
> Linux 39.2%.
> Linux is used by 28.4% of all the websites whose operating system we know.
> Windows is used by 27.6% of all the websites whose operating system we know.
>
И эта доля продолжает падать.
> И эта доля продолжает падать.Но не все об этом в курсе.
> At the end of 2019, Netflix had over 167 million subscribers
> Netflix had 195.15 million paid subscribers worldwide as of the third quarter of 2020
W3C в курсе. 0.4% с трендом к 0.35% за год.
Нетфлих тоже в курсе - у них этот блидинг ёж только на контент кешах, легаси экспериментаторов видимо.
Они это объясняют как "Although it might seem scary to run “development” code in production, we find that it works very well in practice.".
А самый цимес в том, что бздю как платформу клиента нетфлих при этом не поддерживает :D
> W3C в курсе. 0.4% с трендом к 0.35% за год.При этом тебя не смущает, что винда там наравне с пингвинчиком, доля которого чуть ли не в 2 раза уступает "Unknown". Ну и обоснование зависимости мы так и не увидели.
> Нетфлих тоже в курсе - у них этот блидинг ёж только на контент кешах, легаси экспериментаторов видимо. Они это объясняют как "Although it might seem scary to run “development” code in production, we find that it works very well in practice.".
Тот случай, когда нечего сказать и приходится что-то притягивать за уши?
> А самый цимес в том, что бздю как платформу клиента нетфлих при этом не поддерживает :D
То ли дело поддержка невендорлокнутого по самые помидоры пингвинчика для нетфликса или гуглоплея!
Хотя самый цимес в том, что когда очередному опеннетчику нечего возразить, он спешит сменить тему.
Самый цимес в том, что ты даже не пытаешься осмысливать то, что тебе пишут.
> Самый цимес в том, что ты даже не пытаешься осмысливать то, что тебе пишут.Так осмысливать можно что-то осмысленное.
Очередной унылый наброс, с "аргументацией" из надерганых кусков и сделанных на этой основе "выводов", к этой категории не относится.
Я понимаю, что обидно, когда любимка имеет полтора пользователя, пусть даже один из них и нетфлих.
Но увы, факт.
Вы че так волнуетесь?
Бздя если что переходит на пакетный менеджмент системы.
> Вы че так волнуетесь?
> Бздя если что переходит на пакетный менеджмент системы.И че? 5 лет уже как, да и разделение на системную часть и порты отменять пока никто не собирается.
И че? 5 лет уже как переходят, да и разделение на системную часть
и порты отменять пока никто не собирается, а чем конкретно обновляться - дело десятое.
Зачем порты, когда есть контейнеры?
а чем тебе порты помогут?
Ну да, для перловки из цпана гентушники сделали автогенерилку ебилдов - не спасло.
Для чего то то еще вроде хацкеля ( я ужо свалил от этих альтернативных неженок) - тоже сделали и не спасло )))
ну будет у тебя 500к портов на ноду - и че дальше то делать?
Для CPAN и в альте есть средства автоимпорта -- подробностей не знаю, но подозреваю, что это пакет cpan2rpm и что-то возле http://altlinux.org/Packaging_Automation/Преобразование_ПакетовНо человек и впрямь брякнул чушь, не включая голову: или объективные зависимости игнорируем, или нет -- и тогда в таком клиническом случае их... всё равно слишком много.
Проблема дистров, которую они сами же и создали. Дебьяновцы непонятно какой опой думали, когда те же кеды потрошили на тысячу пакетов. А сейчас - ой, чота стало многовато пакетиков, ой, мы не справляемся. С самого начала не надо было заниматься идиотизмом.
Вопрос конечно не по теме, но а какого фига статью выклали в 12:48 если у меня на часах 12:32? И я ток что синхронизировал часы. Может кто-то про этот феномен скажет?
У тебя 13:32
У нас не 13:32, с Часовыми Поясами в последняя время хрень какая-то.
Е=mc2
Е=mc² же.
Э-э-э, а как ты это сделал? Я тоже так хочу!
Юникод. Например:x¹ — U+00B9
x² — U+00B2
x³ — U+00B3Есть ещё и остальные: ⁴⁵⁶⁷⁸⁹⁰ⁱ, но насколько они будут выровнены относительно первых трёх, зависит от шрифта (AFAIR, первые три раньше появились и присутствуют в бо́льшем количестве шрифтов).
> Э-э-э, а как ты это сделал? Я тоже так хочу!https://www.linux.org.ru/forum/general/16096957
Или Compose (Shift+RAlt и ^2)
Посмотри файл /usr/share/X11/locale/en_US.UTF-8/Compose и все это нужно нажимать подряд и получить то что после двоеточия. Назначь себе кнопку <Multi_key> это тот же Compose И набирай<dead_circumflex> <2> : "²" twosuperior # SUPERSCRIPT TWO
<Multi_key> <asciicircum> <2> : "²" twosuperior # SUPERSCRIPT TWO
<Multi_key> <2> <asciicircum> : "²" twosuperior # SUPERSCRIPT TWO
<dead_circumflex> <KP_Space> : "²" twosuperior # SUPERSCRIPT TWO
<Multi_key> <asciicircum> <KP_Space> : "²" twosuperior # SUPERSCRIPT TWO
<dead_circumflex> <KP_2> : "²" twosuperior # SUPERSCRIPT TWO
<Multi_key> <asciicircum> <KP_2> : "²" twosuperior # SUPERSCRIPT TWO
Дожились. Приходится объяснять людям compose.
Е=мс²
E=mcc
И вообще никаких проблем
E=m*c^2 в довесок)
> E=m*c^2 в довесок)да это ж бейсик
EXCEL
...и весь мир узнал что такое "яваскриптопроблемы". )
да ладно, помним, помним про leftpad
Неужто до них начало доходить что не всё подряд нужно пихать в репозитории
> не всё подряд нужно пихать в репозиториитам самая главная проблема - запихали во всё системду, вот с неё надо начинать чистку пакетов.
Правильно, юниксвейный инит должен быть на javascript!
Для некоторых ещё не доходит, что растокарга тоже к этому приведёт.
Если не понимать разницу между пакетами для разработчика и пакетами дистрибутива, то конечно приведет. Надо иногда включать голову, а не механически повторять подход, придуманный для C.
А теперь скажи как решить проблему то. Тут или куча маленьких пакетов, которые никто не поддерживает. Или куча больших пакетов в каждом из которых надо фиксы безопасноти делать при обновлении одного маленького, да еще этот маленький и разных версий. Покожи путь, отче!
Особенно когда растишки решат переписать всю кучу жабоскрипта из новости на священном хрусте!
До них не доходила разница между зависимостями для разработки и зависимостями для рантайма. Точнее, по инерции повторяли схему с .so, не задумываясь, что компилируемые и интерпретируемые (условно, понятно, что сейчас везде под капотом jit) языками - две большие разницы, в интерпретируемых языках можно бить по модулям сколь угодно мелко - там нет проблемы со сборкой под разные архитектуры/дистрибутивы.JS-код (точно так же, как, скажем, PHP или Perl) надо поставлять в виде собранного бандла. Кому надо работать с исходниками, тот будет пользоваться npm (или, соответственно, composer или cpan).
В этом то и дело, что линуксовые пакетные менеджеры созданы для решения проблем сишечки, что само по себе безумие.Не говоря уже о том, что приложения давно не только на сишечке пишут.
ОС ненужны пакетные менеджеры вне базовой системы. ОС нужны менеджеры приложений.
Не линуксовые, а дебиановские.В Arch с самого начала поставляли сорцы и заголовочники в одном пакете с собранными библиотеками. Потому что создатели поняли, что сами по себе source-пакеты не представляют особой ценности.
Вот поэтому минимальные сборки делают из Debian и Alpine, но никогда из арча.Зачем тащить гигабайты мусора, если можно не тащить их?
> ОС ненужны пакетные менеджеры вне базовой системы. ОС нужны менеджеры приложений.Поясни, чем одно от другого отличается. Или пользователю не надо знать какую библиотеку использует его графический редактор для экспорта картинок? Что бы не додумался добавить библиотеку и расширить возможности редактора?
> В поставляемых в репозитории Fedora приложениях, использующих Node.js, разрешено встраивать все имеющиеся зависимости в один пакет, без дробления и выделения используемых библиотек в отдельные пакеты. Встраивание библиотек позволит избавиться от нагромождения мелкими пакетами, упростит сопровождение пакетов (О боже. они открыли для себя jar...
Одобряю, всегда считал что perl/python/ruby/php/js зависимости должны ставиться через пакетный менеджер языка.
+А то заколебался часть библиотек ставить через pip, а сами через apt
А сами через apt*
А часть через apt*Чёртов т9
Помочь хочешь? https://github.com/open-source-ideas/open-source-ideas/issue...
В новости как раз написано, что у Python, Perl и Ruby такой проблемы нет.
Да, у пихона-то проблема - сам впихон. Который сам от себя зависит, и каждый день - новый.
Если пердон из Федоры выкинуть, что вообще от нее останется кроме ядра линукс и системды?
лучше выкинуть системду, тогда останется пихон и ядро.
> лучше выкинуть системду, тогда останется пихон и ядро.Не. на этой картинке лишнее - явно ведро.
Останется системда и пихон. Органичненько.
Ядро - юниксвейно. Пихон - еще как юниксвеен.
Системда - нет. Вот если переписать на JS - получится sys V нового поколения, sys VVV init.
> Ядро - юниксвейно. Пихон - еще как юниксвеен.хм, и что с моим пихоном для б-жественной десяточке не так? Мой yutdl в опасносте?!
> Системда - нет. Вот если переписать на JS - получится sys V
> нового поколения, sys VVV init.Б... ну я ж ем!
Ты эт..не надо такое вслух печатать.
А что, было что-то ценное?yum/dnf - одни из самых убогих поделок в своем классе (потому что rhn ничего не надо).
А что там еще хорошего - або-сратись? Так он вроде сдох.
О том и речь.Последнюю строку твоего клиента я не распарсил.
И да, как же кудзи!
> Последнюю строку твоего клиента я не распарсил.stratis manager жеж, 100% пихонятина.
Загуглил. Какой ужас :-(((
kiss - самый лучший пакетный менеджер всех времен и народов. А еще он на баше.
Баш - не тру. Слишком переусложнен и непрозрачен.Есть показательный критерий простоты и прозрачности языка.
Дайте его обезьяне. Если она сможет на нем написать программу, которая что-то делает, значит, язык прост и прозрачен.И тут баш с треском проигрывает javascript-у.
Может вы и правы, но вот в apt я так и не смог обнаружить порой полезный аргумент который имеется в yum/dnf --disablerepo и --enablerepo
Это с лихвой перекрывается возможностью сделать apt install package/repo.
А если нужно, чтобы репа не наглела при upgrade - есть apt_preferences.
ну моё мнение что у всех такая проблема, просто в ноде она возведена в абсолютну и нода популярнее чем перл какой-нибудь
> нода популярнее чем перл какой-нибудьФантазии смузихлёбов такие фантазии.
>> нода популярнее чем перл какой-нибудь
> Фантазии смузихлёбов такие фантазии.Да не, все правильно - сколько их, умеющих лефтпад, а сколько тех кто еще помнит как на перле написать однострочник?
И вообще - вот ты можешь на перле написать msoffice? А чуваки с нодой наперевес - шмагли!
И задачу следить за уязвимостями или очередным лефтпадом следует переложить с майнтейнера дистрибутива на никого. Это правильно, это современно.Я бы вот предложил и сами нескучные язычки (кроме perl, у которого вообще-то есть средства интеграции с системным менеджером, только вот никто, кроме freebsd, ниасилил) туда же - пользователю в хомяк, пусть иппется как хочет, или, вот, в доскер в доскер под доскер упакует.
Собственно, игогошечка всегда так и делала.
Как раз данное решение упаковывать зависимости в пакет решает проблему с лефтпадом, т.к. в пакете в теории будет лежать рабочая проверенная версия, которая автоматически не превратится в тыкву.
> Как раз данное решение упаковывать зависимости в пакет решает проблему с лефтпадом, т.к. в
> пакете в теории будет лежать рабочая проверенная версияИли нерабочая забэкдоренная, если автомагический механизм непрерывной пересборки всего запустился в неподходящий момент.
Как повезет.
> И задачу следить за уязвимостями или очередным лефтпадом следует переложить с майнтейнера
> дистрибутива на никого. Это правильно, это современно.На автора пакета. Там даже npm audit для этого специально сделали, который весь этот мусор проверяет кое-как )
Пусть каждый сам следит за своими зависимостями, они настолько мелкие и настолько быстрообновляемые, что смысла стараться их выделить в системе в одну общую нет
Ну я и говорю, никого.Автор свою проблему решил давно, и ушел в туман.
А что там за зависимости были - узнаешь когда-нибудь.> Пусть каждый сам следит за своими зависимостями
Я и говорю - все в хомяк! Оно под такую работу только и заточено.
> Ну я и говорю, никого.
> Автор свою проблему решил давно, и ушел в туман.Ну автор же обновляет свой софт иногда. А то вдруг может и за уязвимостями следит, в отличие от задолбанного 100500 пакетами мантейнера %)
>> Ну я и говорю, никого.
>> Автор свою проблему решил давно, и ушел в туман.
> Ну автор же обновляет свой софт иногда. А то вдруг может иАвтор - он в гитхапе или гитляпе. А майнтейнер пакета - вообще не человек.
Причем ему обновлять сам пакет не комильфо, может сломаться. А зависимости надо отслеживать, кто бы этим занялся?
> за уязвимостями следит, в отличие от задолбанного 100500 пакетами мантейнера %)
да щас, учись как надо:
build(deps): bump lyon from 0.17.1 to 0.17.3
@dependabot-preview
@Herschel
dependabot-preview authored and Herschel committed Jan 14, 2021build(deps-dev): bump webpack from 5.13.0 to 5.14.0 in /web
@dependabot-preview
@Herschel
dependabot-preview authored and Herschel committed Jan 14, 2021build(deps): bump bytemuck from 1.4.1 to 1.5.0
@dependabot-preview
@Herschel
dependabot-preview authored and Herschel committed Jan 14, 2021Вишь, кипит у разработчика "работа" !
"А ведь этот еще из лучших"
А как я в таком случе буду Deluge ставить?
> одна библиотека может требовать для стабильной работы одной версии зависимости, а другая - другой. Многие проекты требуют для работы самых свежих версий библиотек, которые не всегда отвечают требованиям дистрибутива к стабильности (в экосистеме Node.js практикуется непрерывное развитие с применением самых свежих версий фреймворков, а дистрибутиву необходима поддержка в течение нескольких лет).расскажите же им уже кто-нить про nixpkg!!!
Они игнорируют nix и всё что с ним связано, придумывая свои велосипеды.
Вовсе не игнорируютНапример: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserL...
Только вот Nix слабо применим на тех же десктопах для неискушенных людей.
> Только вот Nix слабо применим на тех же десктопах для неискушенных людей.почему слабо? и почему поверх apt сделали "применимый неискушёнными людьми" всякие поделки в убунте, а поверх nixpkg не смогут??
> расскажите же имстранно рассказывать что-то поттерингам, которые постоянно велосипедят костыли.
Убоже.
Как там поживает концепция разделяемых библиотек, в никсе? Или "диски большие, схавают"?
> Как там поживает концепция разделяемых библиотек, в никсе? Или "диски большие, схавают"?вы вобще о чём спрашиваете то?
>js
>post-installЧто же может пойти не так...
Видеться мне, в будущем от этого нахватаемся дыр. В npm уже достаточно находили, а теперь без проверок будет тянуться нечто в зависимостях, напрямую из этой свалки.
Какой кошмар, автозамена добавила мягкий знак.
Мягкий знак это ещё полбеды...
Как будто раньше у кого-то руки доходили всю эту мусорку проверять?
Хотя, уже после того как найдут - хотя бы можно было одним апдейтом все и из всех понаустановленных повыпилить. А теперь сам, все сам. Прочавкал очередной лефтпад - твои трудности.
>расскажите же им уже кто-нить про nixpkg!!!чо? как nixpkg справится с этой кучей говна от говноделов, чьей целью было уйти хоть от какого то порядка, лишь чтобы побыстрее слепить свои поделия?
>>расскажите же им уже кто-нить про nixpkg!!!
> чо? как nixpkg справится с этой кучей говна от говноделов, чьей целью
> было уйти хоть от какого то порядка, лишь чтобы побыстрее слепить
> свои поделия?но можно будет прибить гвоздями версии пакетиков для каждого приложения, а не "обязательно с транка"
зы: вы веткой комментов ошиблись при ответе
Но ведь если удалить из реп все нпм и голанг пакеты, нельзя будет больше писать что "у нас больше всех пакетов, аж 51000 штук". А за малое количество пакетов засмеют ведь /s
Евгений Ваганыч, вы что, итешник?
Always have been
>>и добавить в него post-install обработчик для загрузки бэкдоров.А неплохая идея, мне нравится.
> Обратной стороной интеграции станет усложнение процесса доведения исправлений уязвимостей в библиотеках, который потребует скоординированной работы сопровождающих всех пакетов, в которые включена уязвимая библиотека.и это полный пидец
они опять изобрели очередной flatpak!!
закопать js вместе с js-никами. И PHP с Go туда же.
>Debian и Fedora пытаются справиться с проблемой мелких зависимостейТот неловкий момент, когда прочитал заголовок и подумал "Вау! Ну наконец-то избавятся от дробления пакетов на мелкие зависимости, пусть даже это и займет какое-то время". Потом прочитал, что речь о Node.js, NPM... :( Спасибо, не интересно.
Я, было, по названию тоже подумал, что начали копать насчёт deb\rpm. А тут вон эвона оно что..
_Подумать_ стоило о том, почему даже шляпа со своим монолитным perl в итоге пошла за дебианом в подпакетную чащу.Я не знаю, каков именно был их резон, но подозреваю, что тот же: если зависимости не лепить руками как придётся, а генерировать по фактическому материалу, то каждый кусок монолита побольше будет зависеть от половины репозитория (а два таких на обновлении могут просто не разминуться).
А чего в этом хорошего?Захотел поставить Zabbix-агент, а тебе вместе с ним прилетают Zabbix-сервер, Zabbix-прокси и веб-интерфейс Zabbix, а вместе со всеми ними ещё какой-нибудь SQL-сервер (хорошо если только SQLite), PHP, веб-сервер.
Нет уж, лучше пусть продолжают дробить. А то так можно вообще все возможные пакеты сразу в одну систему ставить, пакетный менеджер сразу не нужен: поставил систему и у тебя уже есть всё, что только может понадобиться.
А с npm проблема, как мне кажется, в упоротости разработчиков, пользующихся этой экосистемой. Мне кажется, что там большинство пакетов-зависимостей используется только в поделиях их разработчиков. Среди миллионов чужих пакетов найти подходящий тебе тяжелее, чем добавить свой собственный. Вот и плодятся сотни и тысячи одинаковых по сути, да ещё и разных версий.
> Захотел поставить Zabbix-агент, а тебе вместе с ним прилетают Zabbix-сервер, Zabbix-прокси и
> веб-интерфейс Zabbix, а вместе со всеми ними ещё
> какой-нибудь SQL-сервер (хорошо если только
> SQLite), PHP, веб-сервер.А что в этом плохого? - удивились производители дисков?
Обратили внимание на терабайтные node_modules
Давно перейти к статической линковке всех несистемных приложений. Какой смысл в этой копеечной экономии оперативной памяти. При том что весь софт становится жестко прибит гвоздями даже не к версии ядра, а к версии дистрибутива.
мелко мыслишь, некоторые перешли уже на образы виртуальных машин.
Смысл в простой и быстрой установке обновлений безопасности.
Вот только они не очень-то и нужны за пределами "системных приложений"
Поэтому редактор картинки может помочь хакнуть пользователя.Да, конено, не нужный.
> Давно перейти к статической линковке всех несистемных приложений.Как же звали тех очередных малолетних червоноглазых слакваристов, которые лет пятнадцать назад попытались ровно так и сделать...
В общем, конкретно они засыпались на PAM и OpenOffice, помнится.
Любой десятилетний софт запускаю без проблем. Иногда даже 20 летний нормально работает, это же не венда. Но тогда alsa ещё не было, из-за этого например могут быть проблемы. Ты фантазёр. Статическую линковку обсуждать не буду -- это полная чушь. Но всё же в чём-то ты прав, это либо "всё своё ношу с собой", либо статически, однако, подходит это только для софта который никогда не планирует обновляться в принципе (вообще никогда). И экономия вовсе не копеечная, а гигабайты и гигабайты.
> Любой десятилетний софт запускаю без проблем. Иногда даже 20 летний нормально работает,
> это же не венда.опять цитаты из тысячетомника легенд впопеннета?
Моему DK что-то угрожайет?!> Но тогда alsa ещё не было, из-за этого например могут быть проблемы.
Из-за этого - не могут. Во-первых, уже была, oss это 90е, во-вторых у нее есть эмулятор специально для таких.
> Статическую линковку обсуждать не буду -- это полная чушь.
Мистер Дреппер, вы залогиниться кажись забыли. До вас с вашей м-цкой копипастой из солярки ничем не воняло, у некоторых, не будем пальцем тыкать - весь /{s,}bin был статический!
> подходит это только для софта который никогда не планирует обновляться в
Наоборот. Это идеально подходит для софта, который желает не только обновляться, но и использовать фичи новых версий библиотек, отсутствующих в твоем дистрибутиве. Но хрен вам, или, вот, на игогошечке- она умеет, поскольку не зависит от libc.
>дистрибутивы Линукс столкнулись с проблемой разрастания зависимостей у проектовДа ну, бред какой-то ©
Вот уж слоупоки из слоупоков. На 12-й год Зоркий Глаз заметил, что..
...на флешке есть левый autorun?
Вместо решения проблемы решили её усугубить. Нужно Окончательное Решение Проблемы Устаревших Зависимостей Node.js пакетов в Debian.1. Создать бот, который обходит все GitHub репозитории с пакетами, которые есть в Debian, и проверяет, является ли требуемая версия зависимости - последней самой новой версией.
2. Если не является, создаётся PR, её обновляющий.
3. Если сопровождающий не обновил версию в течение 3х дней, из Debian выкидывается пакет, и все пакеты, зависящие от него.
Ну зачем такие сложности? Можно сразу перейти к последнему пункту без лишних формальностей.
Потому что цель - не выкинуть всё подряд (так можно дойти до того, что выкинуть из дебиана вообще всё), а простимулировать мейнтейнера (или кого-нибудь другого, всё равно, главное чтобы необходимая работа была сделана) сделать свою работу. Если же работу сделать некому, то имеет смысл большинство пакетов, кроме особо нужных, выкинуть (а для особо нужных - таки найти нового мейнтейнера). Кому надо - тот поставит вручную, а в дебиане помойке по типу завендоренных от безысходности зависимостей не место.
> Потому что цель - не выкинуть всё подряд (так можно дойти до
> того, что выкинуть из дебиана вообще всё), а простимулировать мейнтейнера (или
> кого-нибудь другого, всё равно, главное чтобы необходимая работа была сделана) сделать
> свою работу. Если же работу сделать некому, то имеет смысл большинство
> пакетов, кроме особо нужных, выкинуть (а для особо нужных - таки
> найти нового мейнтейнера). Кому надо - тот поставит вручную, а в
> дебиане помойке по типу завендоренных от безысходности зависимостей не место.увы в каждый дистриб (да ещё и со своим незалежным пакетным манагером) мантейнера не найдёшь
если бы была единая "метаинформационная база" по которой зависимости и прочее для пакета можно было бы сгенерить автоматически для каждого незалежного пакетного менеджера + единая база патчей для всех этих дистрибутивов и над патчами могли бы работать сразу несколько разнодистрибных мантейнеров или один мантейнер так мог подготовить единый патч для нескольких разных дистрибов....
Не мейнтейнера пакета в дистре, а мейнтейнера апстрима. Тогда в дистре пакет вообще мейнтейнить не надо, сборочные скрипты всё сделают сами полностью автоматически.>если бы была единая "метаинформационная база"
Есть такая, npm называется.
>единая база патчей для всех этих дистрибутивов
Не нужны патчи, всё должно быть в апстриме.
> Не мейнтейнера пакета в дистре, а мейнтейнера апстрима. Тогда в дистре пакет
> вообще мейнтейнить не надо, сборочные скрипты всё сделают сами полностью автоматически.надеюсь, разработчик и мантейнер у вас разные люди
>>если бы была единая "метаинформационная база"
> Есть такая, npm называется.видимо я чего-то сильно не знаю про npm, например про поддержку сборочных зависимостей и правил версий зависимостей (например жёстких версий или версий в рамках одного релиза)
>>единая база патчей для всех этих дистрибутивов
> Не нужны патчи, всё должно быть в апстриме.что делать, если апстрим отказывается принимать патчи?
что делать, если в коде захардкожены обои, а двух разных дистрибах их хотят разные?
> Окончательное Решение Проблемы Устаревших Зависимостей Node.js пакетовВыпилить к фигам.
Вебмакаки опять всё разговняли? Когда уже уровень вхождения в JS будет выше уровня развития 9классника...
Если бы... Мой в 4 классе на js кодит и ничего, получается. Подозреваю, 50% жскода на гитхабе его разношерстные одноклассники и генерят.
Спасай пацана!
Федоровцами предложили что-то полезное. Я точно не сплю?
У меня схожая дилема с Home Assistant портом во фре, хотя он и на питоне.
Если руками всё делать и ставить как оно хочет, то некоторые версии уже имеющихся портов нужно даунгрейдить, а ещё как минимум сотню портов создать и поддерживать.
Есть и другой вариант, когда в системе будет порядка двух десятков портов которые нужны для запуска а остальное оно само себе через pip докачивает автоматом.
Через несколько ( где N меньше 15) лет ты поймешь,то самым правильным решением будет забить на проблемный пакет, если это не sys-*/.Тем более у вас есть base, там свои игрушки. У меня N равен 7, такие дела.
А можно было не страдать фигнёй и писать изолированные приложения, а не создавать монстров, которые тянут кучу зависимостей )))
Спасибо, но нет) Нам не нужен второй Windows
> А можно было не страдать фигнёй и писать изолированные приложения, а не
> создавать монстров, которые тянут кучу зависимостей )))нельзя, школьники не могут без leftpad, а больше никто ничего хорошего на нескучных язычках не напишет.
Потому что противно.
js в очередной раз аукнулось неконтроллируемое развитие. И это не говоря уже о мгновенном устаревании (и неработоспособности) всего и вся, после появления очередной модной библиотеки.
> js в очередной раз аукнулось неконтроллируемое развитие. И это не говоря уже
> о мгновенном устаревании (и неработоспособности) всего и вся, после появления очередной
> модной библиотеки.Так и задумано. Мгновенное устаревание это фича:-(
А зачем flatpaсk/snap ?
Чтобы на них дзюбить?
Для вендорлока
Чтобы поклоняться им.
Чтобы пихать десктопные приложения в Docker.
Раньше в Fedora/REDHAT была система коллекций, одновременно можно было держать 5 разных node.js 6 python, кучу php и т.д. сразу.
Сказали что это плохо и заменили на модули. Да модули под разные версии но одновременно может стоять только 1.
Новость о другом
> Раньше в Fedora/REDHAT была система коллекций, одновременно можно было держать 5 разных
> node.js 6 python, кучу php и т.д. сразу.а как там это работало? руками в пакетах прописывали python1, python2, python3, ... ?
Ах если бы так. В жизни всё несколько сложнее
https://github.com/ansible/awx/blob/ec1e93cc69a38e92f08c70d2...
А чего ещё было ждать от технологии, где 90% "программистов" програмирует копипастом со стэковерфлоу. Миллион пакетов с 5-10 строчным содержимым - это их спасение.
> А чего ещё было ждать от технологии, где 90% "программистов" програмирует копипастом
> со стэковерфлоу. Миллион пакетов с 5-10 строчным содержимым - это ихзато не копипаста, а модульный принцип разработки и code reuse!
> Обратной стороной интеграции станет усложнение процесса доведения исправлений уязвимостей в библиотеках, который потребует скоординированной работы сопровождающих всех пакетов, в которые включена уязвимая библиотека.это очень плохо
они опять изобрели очередной flatpak!!
странно что про раст не упоминается, там ровно такая же фигня с зависимостями
его кто-то использует? он же как неуловимый Джо!
> странно что про растпод хруст нет реюзабельного кода. он и создавался для забивания баков очередным синтаксисом
Никсы не знают, что делать в ситуации, когда пакеты строго следуют никс-принципу "одна программа - одна фукнция". Это очень смешно
> одна программа - одна функцияпроблема совсем не в этом... веб-макаки наплодили несовместимые js-либы
>Никсы не знают, что делать в ситуации, когда пакеты строго следуют никс-принципу "одна программа - одна фукнция". Это очень смешноWindows знает, что каждая устанавливаемая программа должна весить более 1 Гигабайт, каждая программа для Windows таскаеь с собой все зависимости.
Судя по размерам программ, программы под Windows таскают с собой ещё и копию Windows
То ли дело кocтылинупc: поставь прогу весом мегов в 10 и получи в комплекте ещё гигабайт по зависимостям, ага.
Если ради одной программы устанавливаешь дистрибутив в виртуалку, так и получится. Вот только причем здесь linux?
> никс-принципу "одна программа - одна фукнция".Нет, не так. Одна программа далающая одну функцию ХОРОШО. Сколько библиотек на npmjs хотябы написаны синтаксически правильно, не говорю про великие материи типа api ? Изучите для начала матчасть .
А в чём проблема мейнтейнить только ХОРОШО написанные программы? А не те, которые устаревают через 5 минут после того как их замейнтейнили. Тот же left-pad обновлялся последний раз три года назад и больше не будет.
> А в чём проблема мейнтейнить только ХОРОШО написанные программы?Ну вот я и говорю, в чем проблема ментейнить ХОРОШО написанные программы ? Нет никаких проблем.
>Репозиторий Cargo уже насчитывает более миллиона пакетов, а типовые приложения связываются с сотнями зависимостей, которые, в свою очередь, имеют свои зависимости, что усложняет сопровождение и распространение традиционных пакетов с Rust-приложениями в дистрибутивах Linux.Исправлено.
>В поставляемых в репозитории Fedora приложениях, использующих Node.js, разрешено встраивать все имеющиеся зависимости в один пакет, без дробления и выделения используемых библиотек в отдельные пакеты.
Патрик Фолькердинг одобряет.
Когда нибудь они спохватятся с необходимостью выпила рака systemd, но будет поздно, если уже не поздно
Кому надо - давно повыпиливали и горя не знают.
Вы недооцениваете влияние Шляпы на весь линукс
> влияние Шляпы на весь линуксзаключается в патче для поддержки hpшной клавиатуры, остальное это влияние на наши неокрепшие мозги.
почему же. вот, пожалста, оценяю: линукс - это шляпа. полная. =)
А-хахаха, какой смешной петросян
забавляет, как голосовали в дебиане:
- да, хочу, будет системда
- да, будет системда, хотя и не хочу.
Нормальных библиотек под js не так то и много. Под нормальными подразумевается отсутствие тупых зависимостей и следование стандартам, коим является ES5 и все эти тупоскрипты и сахарок от шестерки признак некомпетентности и говнокода. Весь хардкод под ноду легко выявить простым тестом на следование стандартам - поверьте, там и сотни нормальных библиотек не наберется.
guixsd
Раз уж не удаётся остановить бардак, его нужно возглавить. Как вам идея плагинов к системному менеджеру пакетов для работы с npm/gems/pip/cpan/etc?
> Раз уж не удаётся остановить бардак, его нужно возглавить. Как вам идея
> плагинов к системному менеджеру для работы с npm/gems/pip/cpan/etc?поправил, не благодари!
P.S. а поддержка cpan в pkg_tools была еще в 2000м.
Вот так. https://github.com/open-source-ideas/open-source-ideas/issue...
rm -rf
> Раз уж не удаётся остановить бардак, его нужно возглавить.Насколько понимаю, pypi разрабатывал в т.ч. Андрей Орлов (cray@), который перед тем сопровождал несколько веток питона в альте (ради Zope). Его python packaging policy была в пакете python времён примерно ALT Linux 2.4...4.0, точнее сходу не скажу.
Snap, flatpack же =)
Свой пакетный менеджер должен как-то разруливать эти зависимости. Это же для веб проектов в основном? Ну админу лучше иметь кнопку обновить цепочку зависимостей чем не иметь
Debian и Fedora? Штот это начало конца дебиан
начало конца дебиана - это когда легли под системду
Осталось еще на него вяленого положить и уже можно будет смело переписывать на расте.
Столкнулся с этой проблемой при попытке прикручивании клиента кошелька BitPay/Copay к своему дистрибутиву. Самое примечательное что в разное время на одной и тойже системе пакет может собраться, а может и не собраться из за конфликта версий. Это ужас просто.
История о leftpad и о том, как джабаскрипетры неасилили библиотеки функций с минимизаторами
Не прошло и дцать лет, спохватились.
В целом большинство парадигм дистров устарело.
Мне кажется что это скорее у тебя что-то давно устарело и теперь ты хочешь чтоб ни у кого дист не стоял нормально. Но так не будет, страдай.
Python пакеты, со временем, ждёт та же участь?
на питоне вебмакак гораздо меньше
То чувство когда по заголовку подумал, будто решили перестать наконец-то распиливать одну программу на 5 пакетов по два файла
> то в проектах на JavaScript практикуется дробление на очень мелкие библиотекиОчнитесь. Это проблема не дистрибутивой, это проблема жопоскриптеров и уровня их образования.
Решается очень просто. Выкидываем такие пакеты и всё. Всё равно оно нафик не надо.
>разрешено встраивать все имеющиеся зависимости в один пакет, без дробления и выделения используемых библиотек в отдельные пакетыЮниксвей фсьо?
вебмакаковей
А потом подключать полсотни репозиториев, которые собирают какие-то васяны по каким-то помойкам, чтобы получить что-то большее, чем coreutils/busybox? Потому, что чем дальше в лес тем больше утилит будет переписываться на языках с современной инфраструктурой, а рано или поздно модули и репозитории модулей станут мейнстримом если не в сишечке, то точно в плюсах
Васяны то же ни осилят. Так говно в беззвестности и канет, что пойдет всем только на пользу. Даже автору говна. Будет опыт, что на говне писать нельзя.
Все, что с жс запаковать в какой то snap flatpack и остальное (оно вроде как для огораживания надо как раз) и через это распространять. Из репы выпилить нафиг.
да сразу в образ виртуалки, чего мелочиться
Виртуалки немодно, модно докер.
докер вместе с физическим сервером.
В appliance, да.
Нужен новый браузер - просто докупи железку.
Как js однострочники создают проблему для всех
> однострочникиоднодневники
Уже была идея идти от обратного: обновлять зависимости пакетов персонально для каждого пакета, но в случае совпадения просто оставлять ссыль на один файл? Или это слишком сложно для разработчиков пакетных мененджеров и проще оставить ситуацию, когда устанавливая скажем VLC возникнет конфликт с GIMP (такое почти постоянно в манжаре происходит и каждый раз стрёмно наблюдать за этими телодвижениями)
Что java не нужна, что "стабильные" дистрибутивы в том виде в котором они есть.
Трата ресурсов в пустую.
Экзобарщина полная.
JavaScript - выкинуть и прекратить. Как не умеющие нормально создать удобные иструменты. Не умеющие работать с большим объёмом кода. Неизвестно кем, зачем поддерживаемые.А вот язык Java и стабильные дистры вполне себе удобны и не создают проблем в разработке.
Вот так вот явасценаристы портят жизнь линуксоидам. Хотя казалось бы где явасценаристы а где Linux,
вебмакака сломает всё, что угодно.
Вообще если уж так стали делать, МИКРО зависимости, то это уже в морг. Если МИКРО пакетов стало макро. Ну вот если бы в Питоне делали так, куча микро пакетов - один например для "скачать файл", один для "открыть URL", один для "запросить БД" и тд, ну это было бы ой. Тут только посочуствовать ребятам.
Debian и Fedora - вот ровно то, что нужно знать каждому прыщавому попрыгуну с потными ручонками (арчемэны/бубунтятки) !
Дистров всего два!
Все остальное это провальные породии, болгеносы, тупящие форки, безобразный и извращенский шлак.
Ну, дабы сильно не закидали фекалиями, Slackware припишу ешо... т.е.
Дистрибутивов GNU/Linux всего - два! и слакварь.
Как сразу прост становится этот мир и выбор...
Так бы поступить с ЯП, ваще сказка была-бы.
Искуственно усложненная жизнь, разнообразней? - да... проще? - неть.
Сами себе яму копают. Сначала делят библиотеку на тысячу микро-библиотек по одной функции, а потом мечтают чтобы кто-то эти тысячу библиотек поддерживал. А какой толк от JavaScript библиотек из одной тривиальной функции, где файл лицензии весит больше самого кода, если они не являются разделяемыми библиотеками. Только создают себе головную боль с бесконечно обновляющимися несовместимыми версиями. И это говорит о надёжности приложений написанных на JavaScript, раз каждый день выходит версия исправляющая уязвимость в какой-либо библиотеке.
С другой стороны зачем вообще микро-библиотеки класть в репозиторий дистрибутива, если их приходится обновлять с разной частотой, что вызывает DLLHell. От библиотек в репозитории получают преимущество только разделяемые библиотеки. Укрупняйте библиотеки, чтобы была одна общая библиотеке для всех JavaScript приложений, по аналогии glibc. Ой, а что это микро-библиотеки оказались бесполезными? Ну что поделаешь, нечего было стрелять себе в ногу.
Налицо кризис дистростроения. Идея "а давайте мы запакуем всё-всё-всё" пришла к своему логическому финалу: это становится неподъёмной задачей, особенно если делать полиси "запакуй сейчас и поддерживай за автора 100500 лет после".
> Налицо кризис дистростроения. Идея "а давайте мы запакуем всё-всё-всё" пришла к своему логическому финалу: это становится неподъёмной задачей, особенно если делать полиси "запакуй сейчас и поддерживай за автора 100500 лет после".Налицо кризис программной разработки. Если раньше разрабатывали программы которые могут использовать разные версии библиотек, то теперь мейнстримом считается жесткая заточка на номера версий библиотек. Корень проблемы появившиеся cargo и иже с ними.
Решение простое - положить на них большую кучу. Все-равно такое ..мо сдохнет. Незачем рыпаться ради придурков.