The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Доступен дистрибутив blendOS 3, поддерживающий пакеты из других дистрибутивов, opennews (??), 07-Июл-23, (0) [смотреть все]

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


52. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +3 +/
Сообщение от Аноним (52), 07-Июл-23, 20:48 
А если собрать LFS на принципах:
1 У каждой программы есть домашняя папка (которая имитирует /usr/), с её ресурсами и всеми зависимостями, которые ей нужны. Она ищет их именно там, ld-linux теперь знает про относительные пути и $папка_программы/lib
2 Менеджер пакетов создаёт ссылки из домашней папки пакета-зависимости в пакет, который зависит от него. (ln /usr/pkg/libasound_xx/* /usr/pkg/firefox_xx/)
4 Обычно используются общие библиотеки и мы управляем зависимостями, а не забрасываем пакеты. У нас кроме libasound_xx есть просто libasound, общая системная библиотека по умолчанию. И даже абстрактные папки.

Такой NixOS на минималках взлитит, что будет не так?

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

53. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +1 +/
Сообщение от Аноним (4), 07-Июл-23, 20:51 
На сколько я помню относительные пути зависят от рабочей папки. Собственно тут вся твоя система и рушится.
Ответить | Правка | Наверх | Cообщить модератору

57. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от Аноним (52), 07-Июл-23, 20:54 
Да, пропатчить глубоко, сделав отдельный вид относительных путей, относительно исполняемого файла. (Но мне не нравится такое усложнение, похоже добавляем уязвимостей)
Ответить | Правка | Наверх | Cообщить модератору

63. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от Аноним (4), 07-Июл-23, 21:27 
Вопрос к линуксу и его архитектуры, почему нельзя задать относительный путь относительно исполняемого файла. Но в 70-е годы, когда вся эта система придумывалась, ни у кого никаких проблем с этим явно не было.
Ответить | Правка | Наверх | Cообщить модератору

108. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от Neon (??), 12-Июл-23, 23:53 
А может, спустя пол века, стоит все таки новую архитектуру 21 века наконец придумать. А не жить прошлым ?
Ответить | Правка | Наверх | Cообщить модератору

67. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от Андрюха (??), 07-Июл-23, 22:01 
Это ты сейчас выдумал шындовс. Или флатпак. А не так будут требования к месту на диске. Гигабайт эдак под 70.

Но самое главное не занимаемое пространство, а то насколько неудобно такой цирк обновлять и вообще им пользоваться.
И кстати, ради чего? Чтобы запускать засохший дедовский софт на актуальных пакетах? Или свежие  приложения на каком-нибудь копролите двухгодичной давности?
Так блин ответ в обоих случаях один и тот же: поставь Арч! Или Манжаро если зассал!

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

70. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +3 +/
Сообщение от Аноним (52), 07-Июл-23, 22:25 
Нет, вообще, смотри - обычно всеми зависимостями мы управляем и ссылки ведут на одни и те же файлы. То есть все эти тонны папок - многочисленные дубликаты, а ещё и потенциально связанные именно с абстрактными пакетами "последней версии".
ln /usr/pkg/library.2.5 /usr/pkg/library
ln /usr/pkg/library /usr/pkg/program

Программа обновилась и библиотека в "контейнере" тоже обновилась, если программа не сломается. Фактически это можно заставить вести способом, очень близким к обычным менеджерам пакетов, но мы всё равно можем управлять версиями пакетов, подключать старые репозитории и ставить оттуда ПО. И просто скачивать софт откуда угодно. Это свобода.
А ещё уменьшается дичь со сложностью управления пакетами, разные конфликты и т.п.
На деле наверное не будет очень много места, я надеюсь. Ещё сборка мусора, чтобы удалять пакеты, которые не нужны.
А неудобно почему?

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

72. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +1 +/
Сообщение от Аноним (28), 07-Июл-23, 22:52 
На моём десктопе Дебиан, на моих двух ноутбуках Дебиан, на моих четверых серверах Дебиан. Зачем мне Арч?
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

90. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от unnamed player (?), 10-Июл-23, 15:39 
Никто тебе арч не предлагает, расслабся. Арч - не для ленивых халявщиков.
Но на самом деле арчешкольник из Индии понял раньше анонимусов с опеннета linux-way, проникся идеологией слаквари и арча и пытается сделать красивый дистр с системным подходом.
Ответить | Правка | Наверх | Cообщить модератору

96. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от Аноним (110), 12-Июл-23, 15:14 
>Но самое главное не занимаемое пространство, а то насколько неудобно такой цирк обновлять и вообще им пользоваться.

Что тут неудобного? Обновляешь софтину и всё. Когда захотел - тогда и обновил. И дистриб когда захотел - тогда и обновил. И они друг другу не мешают в этом.
Только места немного больше занимать будет и трафика чуть больше при обновлении. И не 70 (вот уж где сказочники - сами себя пугают как пионэры с байками о гробе на колёсиках), а реально гигов под 10 максимум (ну или если ты совсем уж упоротый софтособиратель, то ну 20). Зато решается сразу вагон проблем.

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

79. "Доступен дистрибутив blendOS 3, поддерживающий пакеты из дру..."  +/
Сообщение от n00by (ok), 08-Июл-23, 09:43 
> А если собрать LFS на принципах:
> 1 У каждой программы есть домашняя папка (которая имитирует /usr/), с её
> ресурсами и всеми зависимостями, которые ей нужны. Она ищет их именно
> там, ld-linux теперь знает про относительные пути и $папка_программы/lib
> 2 Менеджер пакетов создаёт ссылки из домашней папки пакета-зависимости в пакет, который
> зависит от него. (ln /usr/pkg/libasound_xx/* /usr/pkg/firefox_xx/)
> 4 Обычно используются общие библиотеки и мы управляем зависимостями, а не забрасываем
> пакеты. У нас кроме libasound_xx есть просто libasound, общая системная библиотека
> по умолчанию. И даже абстрактные папки.
> Такой NixOS на минималках взлитит, что будет не так?

А в чём вопрос то? Будут ли какие подводные камни, неучтённые на данном этапе? Наверняка будут. И наверняка все решатся на уровне "сел и написал".

Я пока вижу одну нестыковку: в п.4 "мы управляем зависимостями", а в п.2 "менеджер пакетов". Наверное, правильнее назвать его "менеджер зависимостей", он может искать "пакет", или архив с нужными библиотеками, либо отправить запрос на сборочный сервер для компиляции.

И ещё п.3 потерялся.

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру