Сомнительная ценность разраб-софта из репы

стоны что мой дистр не содержит свежей версии

Разве не проще(правильнее) использовать версию, которая идет в репозитории lts убунты?

Ага. У ноды lts это 18, у бубунты почему-то 12

Таки да. Извините ошибся :-)

проще(правильнее)

убунты?

Нет.

Я бы ещё добавил сомнительную ценность этих самых «свежих версий» софта.

А че там по снапу? А то одно в opt клади, потом второе..

У тебя лемминг на аватаре? Значит ты тертый перец :)

Кодить я начал 20+ лет назад, еще на винде, в те времена установка самых разных SDK как раз начиналась с прописывания PATH вручную.

Но теперь я пошел дальше, за годы у меня появилась целая система каталогизации всего нужного, и нынче SDK я прописываю так:

PATH=$PATH:~/reposit/dev/web/node/current
ln -s ~/reposit/dev/web/node/19.0.2 ~/reposit/dev/web/node/current

Это позволяет обновлять/откатывать через замену симлинка.

Всё работает

Это ровно до момента пока все везде совместимо. Задача дистра - чтоб весь софт друг с другом работал. Если либа Х требует версию N, а либа Y - версию M, то одна из либ идёт нафиг.

Задача дистра - чтоб весь софт друг с другом работал. Если либа Х требует версию N, а либа Y - версию M, то одна из либ идёт нафиг.

В своё время был такой замечательный дистрибутив FreeBSD — PC-BSD, в котором каждый пакет приложения вместе с необходимыми ему библиотеками ставился в отдельный каталог и не мешал другим по такому же принципу организованным приложениям.

Формат пакетов — PBI, где каждый пакет наполнялся только необходимыми данному приложению библиотеками из установленной базы пакетов обычной FreeBSD специальным скриптом.

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

Изоляция программного окружения на уровне отдельного приложения — это, конечно, добавляет головняка тому, чтобы обновить все приложения, когда одна библиотека используется в нескольких. Однако в классическом случае пришлось бы точно так же перекомпилировать библиотеку и все зависимые от неё приложения для соответствия новому ABI, поставляя пакеты обновлений для библиотеки новой версии и каждого приложения (которые по сути версий не меняют).

Задача дистра - чтоб весь софт друг с другом работал

Допустим

Если либа Х требует версию N, а либа Y - версию M, то одна из либ идёт нафиг.

Это не связано с предыдущим тезисом, и вообще в целом неверно. Даже для дебиана.

Это не связано с предыдущим тезисом

Связано напрямую

вообще в целом неверно. Даже для дебиана.

Тем не менее к этому и стремятся

ноду

а не проще сразу жрать говно?

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

если завтра этот ганзваген включат по дефолту в десктопных дистрах

Ситуация: всё работает, все довольны. И тут, какой-нибудь Поттеринг: как бы нам испортить жизнь всем пользователям? А, придумал!

Там бинарник ноды почти ни от чего не зависит.

А что не говно? Моча?

есть целая каста сисадминов/девупсов, которые во-первых часто проданы корпам, т.е. везде пытаются затащить какой-нить оффтопик со всеми причитающимся casпёрскими, а во-вторых суть существования которых заключается в генерации таких вот новшеств типа повсеместного ssl с сертификатами и другой бестолковщины делающей им работу. Кроме того, в менеджеры-бизнесмены чаще определяют кроме дезайнеров именно этих товарищей, т.к. они технически обычно малограмотны или узкоспециализированы (т.е. типа ничего не понимают в разработке софта).

Пересобирать что-то, от чего зависит половина дистрибутива, а потом ещё повторять это на куче машин — так себе удовольствие.

Ну, оказалось это просто на твоей локальной системе. А теперь, представь, что в компании работает 200 разработчиков, и продукт устанавливается у 10,000 пользователей. Сразу всё начинает выглядеть иначе. И приходится очередной год сидеть на отвратительно древней Cent OS 7, которая уже вызывает изжогу.

А от бинарника ноды тоже ничего не зависит? Суть стабильного дистра что собранный на нем софт работает независимо от обновлений. Если в ноде версии N+1 что-то поменяли по сравнению с N - в стабильную ветку такое нельзя

сомнительную ценность этих самых «свежих версий» софта

Тут уже упомянули что у ноды lts 18 а в убунте 12. Эта 12 уже нигде не поддерживается в облаках в managed сервисах (типа aws ebs или gcp app). Ну такое.

жрать говно

В смысле ты так и сделал?

ноду

а не проще сразу жрать говно

У тебя в тегах перл, если что

Ставить пакеты средствами пакетного менеджера дистрибутива хорошо потому, что он:

1. проверит зависимости, и если чего-то не хватает, то поставит их - какой-то adhoc-способ либо не сможет поставить зависимость, либо автор пакета стрёмным образом завендроит её без адекватной на это причины;
2. даст мне возможность единообразно обновить все пакеты, а не запоминать, как это сделать в каждом конкретном случае;
3. это не везде и всегда так, но позволит отличить то, что приехало по зависимостям от того, что я поставил руками, чтобы потом удалить лишнее.

Если пакеты бинарные, то:

4. я бесплатно получаю возможность не устанавливать средства разработки (-dev) для того, что мне не нужно. Пакет уже собран в сборочном окружении, где эти зависимости были, что делает результирующие артефакты меньше.

Устанавливая nodejs руками, я лишаю себя части этих преимуществ:

1. когда я обновлю что-то, от чего nodejs зависит по ABI (например стандартные библиотеки C и C++), мне надо будет не забыть обновить nodejs;
2. когда я обновлю сам nodejs, то мне надо будет вручную пересобрать всё то, что с ним слинковано;
3. /* для nodejs напрямую неприменимо */;
4. мне нужны будут компиляторы C и C++, а также заголовочные файлы libsqlite3, чтобы поставить node-sqlite3, а в дистрибутиве уже есть готовый бинарный пакет без лишних runtime-зависимостей.

Всё работает

Ну это пока 😁

Что я сделал не так?

Забыл проверить совместимость с зависимыми компонентами, настроить параметры безопасности, и раскатать это на все тысячи подконтрольных хостов.

Что я сделал не так?

Можно было не ставить ноду и никаких проблем :)

Всё работает. Что я сделал не так? Откуда каждую весну и осень…

подожди полгода и тоже начнёшь стонать :-)

Короч. Теперь как надо xDDD:

$ sudo apt install npm
$ npm install -g npm
$ npm install -g n
$ n stable (или n lts, или n latest, или n currently, или n 14.18.1 вообще рекомендуется n stable)
$ node -v

В аппармор можно написать конфиг для своего софта без проблем. Ну и отключается он тоже просто. Не нужно ныть

Как будто у всех тысячи хостов. Ну а были б тысячи, раскатал бы ансиблом или по ссш. Я так делал ещё больше 15 лет назад.

А зачем гланды через жопу удалять? Volta же есть.

Было бы нужно, опакетил бы. И ставил как полагается из репы. А в опт пихать - это помойка.

Конкретно с нодой самый удобный вариант nvm.

А от бинарника ноды тоже ничего не зависит?

Так это уже головняк того, кто её обновляет сразу после выхода.

я много всяких конфигов перенаписал и эта дрянь не слабже бесконечных ямлей кубера. Не знаю, просто или нет редактирование загрузчиков ОС, но если там фирмварный загрузчик как на RasberyPI то вы просто ничего не сделаете. Вобщем, на лицо «плоды» дружбы убунтоидов с мелкософтом. Также как им нужен плохой джаваскрипт, что-бы впаривать свой тупскрипт, они превращают unix-like в максимально сложный в конфигурировании инструментарий.

там же есть aa-genprof который сгенерит плейсхолдер для конфига. Конфиг не самый удобный, но есть можно. Сендмейл было сложнее конфигурить :))

да ладно, 2-3 софтины поставить в /opt не позорно :)

За двумя-тремя и второй-третий десяток незаметно проползёт. :)

А ты ниасилил? Пичалько.

По мне так вся жабоскриптня говно. Ну ванилька ещё норм, а дальше начинается инфернальный песец. Личное ни на чём не основанное мнение.

ни на чём не основанное мнение.

Такого не бывает. Любое мнение на чём-то да основано.