LINUX.ORG.RU
ФорумTalks

Есть ли дистрибутив полноценно реализующий свободы GPL?

 , ,


0

1

GPL предоставляет получателям компьютерных программ следующие права, или «свободы»:

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

Есть ли хоть один дистрибутив Linux (или другой ОС) в котором все эти свободы действительно бы были, а не только декларировались?

Первая и третья, понятно, есть везде. А вот с остальными двумя всё сложнее.

Предположим, я внезапно захотел изучить, как работает firefox и сделать, чтобы сайты с сертификатом Letsencrypt отмечались как потенциально опасные (подобно нешифрованным сайтам).

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

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

То есть свобода как бы есть, но её реализация напоминает право быть избранным.

Действительную реализацию этих свобод я видел в Emacs (код на Emacs lisp доступен сразу, изменения часто можно сделать просто отдельным файлом, который перекроет нужную функцию), в программах, являющимися локальными сайтами (типа webmin) и в 1С (все типовые программы поставляются в исходниках в предположении, что конечный пользователь будет их допиливать под себя).

Есть ли какой-нибудь дистрибутив, в котором пакеты были бы представлены текущими исходниками + исходниками от поставщика. И при обновлении исходников от поставщика автоматически обновлялись бы текущие исходники как это сделано в git или kdiff3 (а при невозможности автоматического объединения, запускался бы тот самый kdiff3) и автоматически собиралась новая версия бинарника?

В Debian даже файлы в /etc при обновлении не объединяются:

Configuration file `/etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] ? 
★★★★★
Ответ на: комментарий от monk

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

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

то сделайте свой форк проекта и заливайте туда обновления исходного проекта по мере необходимости

Вот это и есть мой тезис, что свободу модификации заменили в реальности свободой создания форков.

Никто не обязан подстраиваться под ваши личные хотелки - это их свобода.

Я не спорю. Но по факту выгодоприобретателями этой свободы являются RedHat и прочие продавцы не совсем свободных дистрибутивов.

А для пользователей только бесплатность (но как у любого freeware в комплекте с безответственностью).

Ладно, раз свобода править код для себя никому не нужна, значит всё нормально. Потому что если нужна, то механизм сохранения доработок вполне можно написать поверх дистрибутива (например, того же Gentoo) и заменить им механизм обновления. Но вот это для себя лично мне точно не надо.

monk ★★★★★
() автор топика

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

dmitry237 ★★★★
()
Ответ на: комментарий от dmitry237

Любой, перечисленные условия не зависят от дистрибутива.

Во всех, мне известных, обновление затирает внесённые пользователем улучшения и нет штатных механизмов их переноса в новую версию.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

обновление затирает внесённые пользователем улучшения и нет штатных механизмов их переноса в новую версию.

Внесенные измения необходимо предоставить автору приложения, если он посчитает их важными, то есть надежда, что они появятся в будущих релизах.

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

dmitry237 ★★★★
()
Ответ на: комментарий от dmitry237

Внесенные измения необходимо предоставить автору приложения, если он посчитает их важными, то есть надежда, что они появятся в будущих релизах.

Именно. То есть, если что-то надо пользователю лично, он идёт лесом. А если посчитает важными, так можно просто багрепорт написать, он и сам сделает гораздо быстрее. Но багрепорт я могу и Микрософту написать примерно с таким же результатом. Зачем тогда исходники?

При том, что есть система, где открытые исходники действительно являются преимуществом перед конкурентами: 1С. Было множество учётных систем, но 1С вытеснила всех именно потому, что в других системах чтобы что-то доделать, надо обращаться к разработчикам (придумал ты, например, себе необычную систему скидок, пиши разработчикам, надейся что реализуют). И сейчас есть тот же БухСофт, который по многим характеристикам лучше, чем программы 1С, но исходников нет, в результате у 1С почти весь рынок.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Вот это и есть мой тезис, что свободу модификации заменили в реальности свободой создания форков.

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

У 1С получилось. И у git получилось. git config --global merge.tool kdiff3 позволяет объединять с новыми исходниками поставщика практически любые изменения (если одни и те же строки изменены, правишь вручную, видя старую конфигурацию поставщика, новую и свою). https://i.stack.imgur.com/wQY9j.png

monk ★★★★★
() автор топика
Ответ на: комментарий от vinvlad

Лицензия, всякие свободы и пр. относятся к базовой неделимой сущности - конкретному проекту.

Свобода модификации и улучшения проекта есть только у автора. У остальных только свобода форкнуть.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

1С вытеснила всех именно потому, что в других системах чтобы что-то доделать, надо обращаться к разработчикам

Я не знаю, как устроен этот программный продукт, но сравнение с дистрибутивом линукс мне кажется некорректным.

dmitry237 ★★★★
()
Ответ на: комментарий от monk

У 1С получилось. И у git получилось.

Ну, вы не путайте git и пакетную систему! Гитовский merge подразумевает персональную ответственность того, кто его выполняет, дальнейшее тестирование и прочие этапы доведения исходников до непосредственного формирования пакета.

1C - это конкретный продукт, в котором предусмотрели какие-то свои возможности добавления расширений. Это не универсальный пример.

vinvlad ★★
()
Ответ на: комментарий от dmitry237

Я не знаю, как устроен этот программный продукт, но сравнение с дистрибутивом линукс мне кажется некорректным.

Пользователю предоставляется программа с исходниками. Пользователь может модифицировать исходники по своему усмотрению (вплоть до того, что в пользовательском интерфейсе есть помощь для поиска в исходниках кода, относящегося к конкретному объекту).

При обновлении запускается механизм аналогичный git merge. В результате у большинства пользователей программ 1С есть порядка полусотни своих изменений.

В линуксе же потенциально можно что-то поправить, но жить оно будет только до обновления.

monk ★★★★★
() автор топика
Ответ на: комментарий от vinvlad

Гитовский merge подразумевает персональную ответственность того, кто его выполняет, дальнейшее тестирование и прочие этапы доведения исходников до непосредственного формирования пакета.

Так у пользователя как и любого человека персональная ответственность перед собой за свои действия неотъемлема. Если только его не признали недееспособным.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

… вы хотите иметь более гибкую систему настроек Firefox UI в плане визуального контроля центров выпуска сертификатов. Ну так обсудите этот вопрос с разработчиками Firefox. К GPL и всяким прочим свободам это не имеет абсолютно никакого отношения. И уж точно недопустимо добавлять предлагаемый вами функционал в пакетные системы - это просто небезопасно.

vinvlad ★★
()
Ответ на: комментарий от monk

Так у пользователя как и любого человека персональная ответственность перед собой за свои действия неотъемлема.

Вы еще предложите продавать маленьким детям огнестрельное оружие!)

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Ну так обсудите этот вопрос с разработчиками Firefox. К GPL и всяким прочим свободам это не имеет абсолютно никакого отношения.

Я не хочу эту систему настроек навязывать всем.

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

Чем именно? Злобный вирус зайдёт под рутом, подправит исходники и будет сохраняться при обновлении? Так он и так может сохраняться, записавшись в бинарник и перехватывая запись этого бинарника.

monk ★★★★★
() автор топика
Ответ на: комментарий от vinvlad

Вы еще предложите продавать маленьким детям огнестрельное оружие!)

Право модифицировать программу, которую используешь лично, настолько же опасно как использование огнестрельного оружия? И все пользователи линукса настолько же безответственны как маленькие дети??? Вы действительно так думаете?

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Я не хочу эту систему настроек навязывать всем.

но хотите всем навязать дополнительную дыру в системе безопасности базового дистрибутива ОС!)

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Каким образом эта функция может являться дырой? Чем она больше дыра, чем нынешняя возможность скачать что-то, скомпилировать, и поставить в /usr/local?

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Чем она больше дыра, чем нынешняя возможность скачать …

Ну, начнем с того, что конкретные юзера не компиляют firefox, а просто устанавливают бинарники. Так что им ваша фича в пакетном менеджере уж точно не нужна. Если же «злобный вирус» внедрится таким образом где-то на сервере, где формируются дистрибутивы для массового использования, то последствия могут быть очень тяжелыми.

vinvlad ★★
()
Ответ на: комментарий от monk

От того, что следующий apt upgrade всё удалит.

Зависит все от тебя, куда поставишь и так далее. Посмотри как сделано в хроме, когда ставятся сразу три версии. Да придется портировать свои изменения под каждый новый выпуск ФФ или проталкивать их в апстрим, тяжела жизнь мейнтейнера форка, так как по факту так и есть. В случае ФФ есть шанс воспользоваться расширениями если требуемый функционал может быть реализован в них.

Могу на примере smb.conf.

Дефолт всегда сохраняется рядом с измененным конфигом запускаешь диффтул и вперёд адаптировать дефолт под свои хотелки. Из опыта могу сказать, что случаев ошибок в старых конфигах при обновлении на новую версию было один или два раза.

einhander ★★★★★
()
Ответ на: комментарий от vinvlad

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

Так они потому и не компиляют, что нет такой фичи. Впрочем, всё равно компиляют в source-based дистрибутивах.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

При обновлении запускается механизм аналогичный git merge. В результате у большинства пользователей программ 1С есть порядка полусотни своих изменений.

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

dmitry237 ★★★★
()
Ответ на: комментарий от dmitry237

Но когда речь идет о наборе разномастных программ, написанных на разных языках, у каждой из которых свои разработчики, это просто невозможно.

Почему? Предположим, я захотел сделать такую возможность для Debian.

Мне нужны следующие команды-утилиты:

  • repo-init

Перебирает все установленные пакеты и для каждого делает apt source в /usr/src/repo

  • repo-get <имя пакета>

Копирует исходники пакета из /usr/src/repo в /usr/src/current/<имя пакета>

  • repo-commit <имя пакета>

Собирает пакет из /usr/src/current/, устанавливает его через dpkg, записывает имя в файл с именами изменённых пакетов.

  • repo-upgrade

Вытаскивает список пакетов для обновления через apt, для каждого обновляемого изменённого вытаскивает новый исходник, объединяет через kdiff3 новый, старый и текущий. Получает новый текущий, собирает пакет.

Обновляет все остальные пакеты, ставит новые версии изменённых.

Для всех обновлённых скачивает новые исходники в /usr/src/repo

  • repo-restore <имя пакета>

Устанавливает пакет из дистрибутива. Удаляет из списка обновлённых.


Всё. С поправкой на команды получения исходников и обновления можно адаптировать для любого дистрибутива.

monk ★★★★★
() автор топика
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Оно может одновременно открывать вкладки в разных профилях в пределах одного окна? Может автоматически по клику по ссылкам заданных доменов открывать вкладки в определенных профилях (опять-таки в пределах одного окна)?

Или мне нужно запускать отдельную копию браузера с нужным профилем?

theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)

Честно говоря не предстваляю как такое может работать. В Guix, например, можно сделать свой пакет из стандартного и добавить в процесс сборки стадию наложения ваших заплаток. Так ведь это от фока firefox ничем почти не отличается, с каждой новой версией нужно будет заплатки подстраивать (ну, по крайней мере проверять на совместимость).

ugoday ★★★★★
()
Ответ на: комментарий от theNamelessOne

Насколько я понял, да. Но я не пробовал.

monk ★★★★★
() автор топика
Ответ на: комментарий от ugoday

В Guix, например, можно сделать свой пакет из стандартного и добавить в процесс сборки стадию наложения ваших заплаток.

Выше писали про аналогичную штуку в NixOS.

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

Честно говоря не предстваляю как такое может работать.

У 1Сников работает. Так сказать, доказательство реализуемости. А там тоже программы с миллионами строк кода.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Почему?

Потому, что тогда необходимо для каждого отдельного пользователя организовывать уголок в repo для его патчей. Сколько этих пользователей никто не знает, что они туда накоммитили тоже, кто будет нести ответственность за работоспособность софта? Умельцев каждый второй, и каждый третий будет засыпать дистроделов тупыми вопросами «а почему у меня не загружается ядро, я туда впендюрил патч, он у меня в коммитах, посмотрите». А другие будут говорить зачем нам вот это вот все, мы хотим просто установить и пользоваться, не нужны нам не коммиты ни патчи.

Вы с таким же успехом можете скачать исходники и сами собрать пакет.

dmitry237 ★★★★
()
Ответ на: комментарий от monk

Кажется понял. Вы хотите что-то типа: а) есть программа s1 и заплатка p1, заплатка применяется, программа собирается, всё хорошо; b) вышла новая версия s2, применяется заплатка p1, всё хорошо; c) вышла несовместимая версия s3, применятеся заплатка p1, сборочный процесс падает, автоматически создаётся сборочное окружение, где есть s2, s3, p1, все нужные средства, чтобы подогнать p1 к s3.

Так? Ну, прям вот совсем такого нету, но есть guix shell, в котором можно легко создать интерактивное окружение для какого-то пакета и в нём развлекаться как вам вздумается. В принципе близко.

ugoday ★★★★★
()
Ответ на: комментарий от dmitry237

Потому, что тогда необходимо для каждого отдельного пользователя организовывать уголок в repo для его патчей. Сколько этих пользователей никто не знает, что они туда накоммитили тоже, кто будет нести ответственность за работоспособность софта?

В смысле? У пользователя его личные патчи. В личном каталоге. Дистроделам не должно быть никакого дела до его патчей.

Также как сейчас вполне можно локально поправить .emacs и rc.local и никакого уголка для патчей для этого не надо.

Вы с таким же успехом можете скачать исходники и сами собрать пакет.

Могу. Но после этого не могу обновлять дистрибутив. Потому что либо при обновлении мой пакет затрётся типовым более новой версии либо я фиксирую пакет, тогда он перестаёт работать когда все библиотеки в дистрибутиве уходят на новую версию.

При наличии repo-update из исходников моего пакета из /usr/src/current, типовых исходников до обновления и типовых исходников после обновления автоматически (или почти) будет собран пакет новой версии с моими изменениями. Что в этом плохого?

monk ★★★★★
() автор топика
Ответ на: комментарий от ugoday

В принципе близко.

Исходников s2 в нём нет после того как p1 не наложился на s3. А без них патч редактировать на порядок сложнее.

Для GUIX надстройку надстройку делать чуть проще, но всё равно надо.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Ваш случай уж очень нестандартный, так что кроме «можно сделать» вряд ли чего и ответишь. Но, по крайней мере, в этих наших линуксах это можно сделать, что уже хорошо.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Ваш случай уж очень нестандартный

Именно поэтому тему и поднял. Потому что во времена, когда самым популярным дистрибутивом был Slackware, этот случай был стандартным. Патчили практически всё: от веб-сервера до mc.

Потом я ушёл в 1С и подсознательно был уверен, что ничего не изменилось… К тому же, в 1С тогда тоже не было нормальной интеграции с kdiff3.

А теперь осознаю, что на современном дистрибутиве такая простая операция, как поправить скачанный tgz и пересобрать, совсем не простая. А с учётом необходимости обновляться, ещё и малоосмысленная.

А теперь, судя по комментариям в этой статье, вообще не понимаю, в чём теперь смысл внедрения Linux. С таким же успехом можно внедрять любой freeware. Или тот же docker, который неясно как собирать из исходников (и где вообще исходники). Или vscode, который несвободен, но популярен.

monk ★★★★★
() автор топика
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

самым популярным дистрибутивом был Slackware

В стиле слаки вы и сейчас можете, как известно, ./configure && make && sudo make install превращает любой дистрибутив в Слакварь.

А теперь, судя по комментариям в этой статье, вообще не понимаю, в чём теперь смысл внедрения Linux.

Plan9 не взлетел, *BSD умерли все, так что альтернативы особо и нету.

Или тот же docker, который неясно как собирать из исходников (и где вообще исходники).

здесь https://github.com/moby/moby, насколько я понимаю. (остальная часть в ядре).

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

В стиле слаки вы и сейчас можете, как известно, ./configure && make && sudo make install превращает любой дистрибутив в Слакварь.

Это понятно. Но после этого обновления ломаются.

здесь https://github.com/moby/moby, насколько я понимаю. (остальная часть в ядре).

Написано:

The components and tools in the Moby Project are initially the open source components that Docker and the community have built for the Docker Project.

Из этого точно можно собрать Docker Desktop или хотя бы Docker Engine?

Plan9 не взлетел, *BSD умерли все, так что альтернативы особо и нету.

Я про то, что новые проекты будут открыты в том смысле, в котором открыты docker, VSCode и Android. И привязывать производители будут также, как Google привязывает к Андроиду. В общем, линукскапец таки наступил.

monk ★★★★★
() автор топика
Последнее исправление: monk (всего исправлений: 1)

Вот это тебя вштырило.

ox55ff ★★★★★
()
Ответ на: комментарий от thunar

Как у nix с QA

Насчёт ручного QA не в курсе, а так различные срезы дистра и пакетов периодически собираются в CI.

Ты можешь ставить пакеты с любой Git-ветки, тэга или коммита (можешь даже ставить одновременно с разных коммитов). Кроме того есть т.н. «каналы» — специальные срезы дерева пакетов (про каналы и то, как они обновляются, а также про зависимость процесса обновления от результатов сборки в CI, можно подробнее почитать тут).

Я сейчас сижу на канале nixos-unstable, и не припомню на моём опыте, чтобы там что-то ломалось (я обновляю систему раз в пару месяцев, либо когда нужно что-нибудь новое поставить, чего нет в текущем срезе). Раньше вообще сидел на ветке master, там изредка ломались пакеты, как это обычно выглядит на реальном примере: пересобираю систему, фейлится сборка громоптицы. Из-за этого останавливается пересборка, в итоге остаёшься на текущей рабочей версии системы (как если бы ты пересборку не запускал). Отправляю багрепорт, через 5 минут его закрывают как дубликат, через 4 часа фиксят. Я в итоге ушёл с master на nixos-unstable не из-за таких редких багов, а потому что если сидишь на master, часто пакеты пересобираются из исходников, потому как собраемые в CI пакеты не успевают попасть в бинарный кеш.

Кроме того у NixOS есть одна очень полезная особенность: каждая пересборка мира создаёт новую «версию» твоей системы — generation. У тебя может существовать одновременно несколько генераций, одна из которых будет активна. Ты в любой момент можешь переключиться на старую генерацию во время загрузки ОС в меню GRUB/systemd-boot, если что-то пойдёт не так (только если ты её не удалил).

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

и адекватностью дефолтов?

Не знаю, как на это ответить. Наверно, нормальные? У меня претензий к дефолтам не было.

theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 3)
Ответ на: комментарий от monk

Но после этого обновления ломаются.

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

или хотя бы Docker Engine?

Судя по docker.scm можно (я лично не проверял).

новые проекты будут открыты в том смысле, в котором открыты docker, VSCode и Android.

Если вернуться к началу, то GPL обязывает открыть только код. Существует ли лицензия, обязывающая открыть ещё и работу сборочного окружения — не знаю, но сильно сомневаюсь.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Либо трусы, либо крестик.

Я же предложил алгоритм работающего решения.

Судя по docker.scm можно (я лично не проверял).

Да. Вижу в нём остальные куски.

Существует ли лицензия, обязывающая открыть ещё и работу сборочного окружения — не знаю, но сильно сомневаюсь.

Вот и я про то же. Source-based дистрибутивы спасают от полной блокировки сборки. Но чем дальше, тем меньше ценности дают исходники для пользователя. В пределе будет как у Андроида: даже имея исходники, установить изменённую версию достаточно проблематично (кстати, опять исключая 1С: они в свою мобильную версию воткнули фактически JIT компилятор и исходники программы).

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Вы с таким же успехом можете скачать исходники и сами собрать пакет.

Могу. Но после этого не могу обновлять дистрибутив. Потому что либо при обновлении мой пакет затрётся типовым более новой версии либо я фиксирую пакет, тогда он перестаёт работать когда все библиотеки в дистрибутиве уходят на новую версию.

Если взять к примеру Debian, то можно формировать свои личные кастомные пакеты и устанавливать их посредством dpkg вообще не связываясь с apt/apt-get. Тогда ничего затираться не будет, если имя бинарника выбирать тоже свое.

vinvlad ★★
()
Ответ на: комментарий от monk

… у меня, к примеру, есть виртуальная машинка, где можно устанавливать и использовать несколько версий Firefox и Google Chrome. В свое время законфигурил такую для тестирования frontend-приложений. apt-get update/upgrade там тоже работает - никаких конфликтов не возникает.

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от vinvlad

Тогда ничего затираться не будет, если имя бинарника выбирать тоже свое.

Можно. Делал. Через несколько версий бинарник перестаёт запускаться. Можешь сам попробовать установить десяток пакетов из stable в unstable, в среднем половина перестанут работать.

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

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Можно. Делал. Через несколько версий бинарник перестаёт запускаться. … Надо, чтобы вытаскивались новые исходники и к ним применялись актуальные изменения.

Ну правильно. Ты же не обновлял свой кастомный пакет. Просто ставь и обновляй стандартный пакет исходников Firefox. И при каждом его реальном обновлении заново формируй и устанавливай свой кастомный пакет на основании текущих исходников стандартного пакета.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

И при каждом его реальном обновлении заново формируй и устанавливай свой кастомный пакет на основании текущих исходников стандартного пакета.

Вот этот процесс мне и нужен. Ищу дистрибутив, где он более-менее автоматизирован, чтобы пользователям было удобно делать кастомные пакеты. Если такого нет, изучаю мнению, нужно ли оно вообще кому-то кроме меня и надо ли писать что-то вроде алгоритма по ссылке.

Пока вижу, что не нужно, ибо пользователи линукса безответственны как дети.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Вот этот процесс мне и нужен. Ищу дистрибутив, где он более-менее автоматизирован,

Ну, такой дистрибутив вы вряд ли найдете. Но написать свое wrapper-приложение вокруг apt-get, которое будет делать все что нужно и поддерживать актуальность кастомных пакетов, вполне можно.

… ибо пользователи линукса безответственны как дети.

Вы предлагаете всем пользователям Linux индивидуально превращаться в разработчиков и модифицировать-компилять все пакеты? Это как-то уж совсем неправильно) Для этого есть соответствующие компании, поддерживающие соответствующие дистрибутивы Linux.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Вы предлагаете всем пользователям Linux индивидуально превращаться в разработчиков и модифицировать-компилять все пакеты

Да. У 1С получилось успешно. При том, что потенциальный пользователь 1С — это бухгалтер или кадровик, а потенциальный пользователь Линукса — это сисадмин или программист.

Это сделало бы Линукс действительно на порядок удобнее любой конкурентной системы. И создало бы рынок специалистов, аналогичных 1С-франчайзи, которые на месте помогали бы пользователям реализовать любую хотелку.

Для этого есть соответствующие компании, поддерживающие соответствующие дистрибутивы Linux.

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

Это всё равно, что попросить добавить проводку в 1С не местного мальчика из франчайзи 1С, а саму фирму 1С. Они это делают, но стоимость доработки начинается от 100 тысяч рублей.

monk ★★★★★
() автор топика
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)