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] ? 
★★★★★
Ответ на: комментарий от cobold

В генту есть /etc/portage/patches , куда можно бросить патч и он автоматом будет применяться при сборке пакета. Другое дело, что патчи имеют свойство протухать и все равно их придется поддерживать… Ну тут уж извините, хочешь свободы - хоти и лапками грести хоть немного.

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

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

Ну, это вы загнули. Сплошь и рядом открыты вакансии «программист 1C». Бухгалтеры и кадровики являются лишь пользователями каких-то типовых поставок 1С или систем, настроенных их штатными программистами.

Они не работают по индивидуальным заказам.

Ну, напишите свое wrapper-приложение (см. выше) и попробуйте протолкнуть его в базовый дистрибутив. Или просто сделайте для него deb-пакет и выложите его где-нибудь в инете, снабдив соответствующей инструкцией по установке. Bash-a, я думаю, вполне хватит для написания такого приложения, так что и заморачиваться с сопровождением особо не придется.

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

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

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

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

Ну, это вы загнули. Сплошь и рядом открыты вакансии «программист 1C». Бухгалтеры и кадровики являются лишь пользователями каких-то типовых поставок 1С или систем, настроенных их штатными программистами.

Программист 1С не является пользователем. Он является помощником пользователя.

Или просто сделайте для него deb-пакет и выложите его где-нибудь в инете, снабдив соответствующей инструкцией по установке.

Я пытаюсь понять, надо ли оно вообще кому-то. В стол работать лень.

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

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

Продаем/раздаём debian-rf с суперфичей «можно сделать всё как лично Вам надо».

Цена точечной доработки порядка тысячи рублей (как в 1С), доработки сохраняются при обновлении.

Можно менять клавиатурные комбинации в Gnome, добавлять флаги командам, добавлять журналирование выполнения команд, …

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

Есть source-based дистрибутивы. Всё перекомпилируется. Но изменения исходников пользователем там не предполагается.

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

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

Не-не-не, я спрашивал пример такой «точечной доработки». Всё, что мне приходит в голову, либо не требует правки исходников вообще, либо — большой проект, где поставка артефакта пользователю — наименьшая из возможных проблем (да и в бюджет «порядка тысячи рублей» радикально не укладывается). Но я признаю, что могу чего-то упускать.

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

Не-не-не, я спрашивал пример такой «точечной доработки».

Пример из статьи не подходит? Сделать, чтобы если сертификат DV (без заполненной организации), чтобы адрес выводился красным шрифтом.

Может быть, конечно, можно как-то и расширением извратиться, но сомневаюсь.

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

Но сейчас польза от открытых исходников только для разработчиков. Для пользователей только бесплатность (и то условная, так как тот же RHEL очень даже платный).

Так всегда было, Карл!

1C

А почему это корректная аналогия?

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

А почему это корректная аналогия?

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

Читал, что когда-то на лисп-машинах также было (исходники были прямо в системе и можно было перекомпилировать любую функцию или файл целиком без остановки системы). Как сейчас elisp в Emacs.

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

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

Это не аналогия

Я не знаю, что там в 1С, но зачем ты приводишь этот пример? Хочешь сказать, что и ядро многозадачной ОС уровня Линукс можно сделать простым для модификации рядовыми пользователями?

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

Именно так и было. Без серьезного знания сишки и системного программирования хрен ты что сделаешь в ядре. И с лиспом твоим та же история.

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

Хочешь сказать, что и ядро многозадачной ОС уровня Линукс можно сделать простым для модификации рядовыми пользователями?

Я ещё застал то время, когда ритуальная компиляция ядра каждым пользователем была практически обязательна, а «ванильное» ядро использовали только новички. И эта компиляция иногда сопровождалась и точечными корректировками для себя.

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

… Продаем/раздаём debian-rf с суперфичей «можно сделать всё как лично Вам надо».

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

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

Там ещё наложение патчей было.

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

Юридические лица с рабочими станциями на Линуксе.

Но на них может быть наложено ограничение - использовать только одобренный «государством» дистрибутив Linux. А вы планируете менять «одобренный» базовый софт.

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

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

А сурс-пакеты не подходят для этого, src-rpm, PKGBUILD, SLACKBUILD, deb-аналог? У меня такой необходимости не было и я только предполагаю, но вроде можно просто сохранить измененный условный «spec-файл» и при следующем обновлении он должен подхватиться. Останется только натравить пакетный менеджер на сурс-репу для определенного пакета.

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

А вы планируете менять «одобренный» базовый софт.

Так они его и так меняют. Скрипты в /etc, например.

Не, если там сертификат ФСТЭК, контрольные суммы на бинарники и запрет запускать что-либо кроме оговоренного списка, то сделать, естественно ничего нельзя.

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

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

Выше обсуждали. Заменить пакет своим можно. Проблема при обновлении. Новая версия просто затрёт изменения. А если поставить, чтобы пакет не обновлялся, он через несколько обновлений работать перестанет (так как все библиотеки обновились) или обновление застопорит (если зависимости прописать к версиям).

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

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

Новая версия просто затрёт изменения

Почему? Вы же сами будете собирать, пакетный менеджер только скачает исходники, когда появится новая версия. А дальше вы их распаковываете, собираете пакет и устанавливаете. Я так представляю этот процесс, может и ошибаюсь.

Просто не логично для сурс-пакетов, чтобы они собирались автоматом. Зачем тогда «someapp.src.rpm», когда есть «someapp.rpm»?

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

Просто не логично для сурс-пакетов, чтобы они собирались автоматом. Зачем тогда «someapp.src.rpm», когда есть «someapp.rpm»?

Из «someapp.src.rpm» делается «someapp.rpm» и ставится. Если имя и версию не менять, то поставится вместо штатного. Если поменять, можно поставить дополнительно, но тогда при изменения штатного надо следить вручную.

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

Конечно nixos или guix. Тебе больше зайдёт scheme, но говорят из-за отсутствия ленивости есть нюансы.

Puzan ★★★★★
()

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

Сначала тоже на это триггерился, но - откуда оно должно понять, как их объединить правильно? Если просто механически «новый конфиг + изменённые строчки из старого», то на выходе часто получится сломанный сервис и ручной пердолинг пострадавших конфигов. Дебиан ещё и по сути серверный, там просто обновление убивать систему будет с таким подходом.

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

Если просто механически «новый конфиг + изменённые строчки из старого»

Там есть Z. Если бы в этот момент был доступен distold, distnew и текущий, вопросов бы не было. Но чтобы в этот момент вытащить distold, надо постараться (сделать машину времени и скопировать его до того, как начал редактировать, или вытащить из пакета старого дистрибутива).

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

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

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

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

Ну у deban есть возможность загружать исходные коды из репозитория с фирменными патчами, накладывать на них свои патчи и собирать как пакет для установки в локальную систему - не то что ты ищешь?

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

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

На самом деле тебя поджидает еще одна проблема: зависимости 😱😱😱. Тысячи мелких пакетов, которые непонятно как разбиваются, собираются из одного, тянут другие, несовместимы с третьими. Лавкрафтовские сборочные скрипты добьют, что бы написать их самому с нуля, и все понять, нужно реально так засесть и изучать.

ПМ все равно что пакеты бинарно совместимы, он будет вставлять палки в колеса. Проблема признана, в Debian настойчиво просят не мешать пакеты, иначе все сломается.

Единственная система которая мне не мешала кастомизировать систему это Slackware. dev пакеты не требуют отдельной установки, по умолчанию установленная система способна сама себя собрать. Подобные проблемы невозможны. Я постоянно собираю себе что то новое, или что то старое, сейчас использую Xfce 4.12 2015 года, потому что она лучше современной.

Еще в Slackware есть SlackBuilds.org, и sbopkg. sbopkg это ПМ для SlackBuilds.org, с поддержкой TUI. SlackBuilds.org это то что ты хочешь, исходники берутся от производителя приложения.

Еще в Arch нормальные PKGBUILD есть, синтаксис простой. Но там тоже зависимости, и RR значит что ты будешь пересобирать свои приложения каждый день, или не будешь обновляться никогда, потому что если ты будешь обновляться раз месяц он развалится.

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

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

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

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

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

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

Так у модифицированного пакета ведь имя и версия не меняются. С точки зрения ПМ это тот же пакет.

Собственно, поэтому и надо переносить изменения на новую версию при каждом обновлении дистрибутива.

Единственная система которая мне не мешала кастомизировать систему это Slackware.

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

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

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

В случае 1С я продаю услугу обновления. Которая включает в себя перенос всех сделанных доработок. Не переносится только если либо 1С уже сделало аналог доработки либо если доработка касалась удалённого объекта (попросили передвинуть кнопку, в новой версии этой кнопки нет).

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

Смеёшься? В 1С регулярно ломают API и меняют структуру данных.

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

В случае 1С я продаю услугу обновления…

Вот именно! И это происходит не так уж часто по сравнению с обновлениями дистрибутивов Linux, которые выполняются автоматически - и возможно каждый день. Вы реально собираетесь ручками обновлять Linux у всех ваших клиентов зарубив автоматическое обновление?

Смеёшься? В 1С регулярно ломают API и меняют структуру данных.

Тем не менее, это «обломы» как-то отражаются в документации. Согласись, что отдокументированные изменения в API поддерживать проще, чем изменения в «черном ящике» просто исходного кода.

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

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

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

Вы реально собираетесь ручками обновлять Linux у всех ваших клиентов зарубив автоматическое обновление?

Наоборот же. Я хочу, чтобы было автоматическое обновление, переносящее доработки (в стиле git merge), которое вручную допиливать надо один раз из ста.

Тем не менее, это «обломы» как-то отражаются в документации.

Не сыпь соль на рану. В документации «Мы сделали новую возможность для пользователя: … Сделали новый отчёт … Исправили ошибки.» Последняя фраза подразумеваете как раз все переименования модулей, функций, реквизитов, …

Linux с его stable api nonsense на фоне 1С является просто образцом стабильности и документированности.

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

Не сыпь соль на рану…

Ну тогда заявы типа «у 1С получилось» мягко говоря не соответствуют действительности ))

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

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

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

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

Так у модифицированного пакета ведь имя и версия не меняются.

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

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

Чинить тоже легко, если у тебя time_t разных версий, то тебе по любому пересобирать пакеты массово придется. ПМ тебе будет сыпать ошибками и мешать это делать.

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

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

1C, пусть и с переменным успехом, но формально поддерживает франчайзинговую программу. Дистрибьютеры Linux-а никакого франчайзинга не поддерживают - можно просто стать дополнительным дистрибьютером, используя в качестве источника upstream-дистрибутивы - типа Debian. Но это сложно. По сути, вы просто хотите стричь «бабки» на установке и настройке Linux, а все идеи типа отдельной иконки для Letsencrypt-сертификатов - просто маркетинговая страшилка-замануха для выделения среди прочих конкурентов. Как-то вот на это больше похоже, хотя может вы для себя это и обосновываете по другому)

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

ПМ тебе будет сыпать ошибками и мешать это делать.

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

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

1C, пусть и с переменным успехом, но формально поддерживает франчайзинговую программу.

У франчайзи всего одно право: купить у 1С за полцены и кому-то продать. Всё остальное делается без 1С. Я сопровождаю 1С не являясь франчайзи.

По сути, вы просто хотите стричь «бабки» на установке и настройке Linux

Мне 1С хватает. Я хочу, чтобы кто-нибудь другой стриг бабки на установке и настройке Linux.

все идеи типа отдельной иконки для Letsencrypt-сертификатов - просто маркетинговая страшилка-замануха для выделения среди прочих конкурентов

Это был просто пример из диалога. Ответ на вопрос «а зачем нужны исходники».

Просто сейчас для пользователя Linux «это такой бесплатный Windows, только в нём другие программы». И никакого смысла от перехода он не видит (хуже точно станет, так как вместо MS Office и Adobe надо привыкать к другим программам). С учётом того, что Windows пользователь тоже воспринимает как бесплатную (компьютер без ОС и с Windows стоит практически одинаково), то заставить перейти удаётся только как-то запретив использовать Windows (как бюджетников).

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

… Я сопровождаю 1С не являясь франчайзи.

1C - это по своей сути полуфабрикат, ну или точнее 4GL, т.е. среда, изначально предназначенная для доводки третьими лицами. Отдельные пакеты Linux-дистрибутива таковыми в подавляющем большинстве не являются. Поэтому идея переноса «подхода» здесь не работает. Чисто для себя вы конечно можете что-то подгонять и править как вам хочется. Но как только речь заходит о распространении ваших патчей среди сторонних юридических лиц, то возникают серьезные вопросы, на которые вы внятного, серьезного ответа не даете.

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

1C - это по своей сути полуфабрикат, ну или точнее 4GL, т.е. среда, изначально предназначенная для доводки третьими лицами.

Ну почему же? Есть базовая версия 1С, в которой заблокировано редактирование исходного кода. И её достаточно массово покупают.

Изменение исходного кода это возможность, а не необходимость.

Отдельные пакеты Linux-дистрибутива таковыми в подавляющем большинстве не являются.

Потому что так приучили. Вот вам конфигурационный файл и опции, остальное трогать нельзя.

Но как только речь заходит о распространении ваших патчей среди сторонних юридических лиц, то возникают серьезные вопросы, на которые вы внятного, серьезного ответа не даете.

А в чём проблема? Есть infostart.ru, который как раз площадка по обмену такими патчами.

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

Изменение исходного кода это возможность, а не необходимость.

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

Есть infostart.ru, который как раз площадка по обмену такими патчами.

Какая связь между infostart.ru и Linux?

Если вы не осознаете/признаете принципиальную разницу между дистрибутивом операционной системы, и вполне конкретным одиночным продуктом 1С, то разговор просто не имеет смысла. Флаг вам в руки)

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

В Debian у пакетов есть метка t64, по ней в Slackware найти пакеты так же легко.

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

Какая связь между infostart.ru и Linux?

Что мешает аналогично распространять свои патчи? Или про что вопрос «о распространении ваших патчей среди сторонних юридических лиц, то возникают серьезные вопросы, на которые вы внятного, серьезного ответа не даете»?

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

А дистрибутив не является продуктом/набором продуктов?

Если вы не осознаете/признаете принципиальную разницу между дистрибутивом операционной системы, и вполне конкретным одиночным продуктом 1С

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

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

… Что мешает аналогично распространять свои патчи?

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

А дистрибутив не является продуктом/набором продуктов?

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

Сопровождают на языке 1С обычно не конкретный продукт, а все, используемые клиентом.

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

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

Их непрогнозируемое «протухание»

Они же в исходниках. Поддерживать может не тот, кто написал. В мире 1С есть куски кода, у которых даже автор неизвестен (типа «народное творчество»).

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

Это вообще к бесплатному софту относится. В открытом можно хотя бы проверить.

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

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

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

Это и есть сопровождают.

И кроме того - не все продукты, а лишь то, что связано с учетом, логистикой и прочей «бухгалтерией».

Не только. На 1С и системы резервного копирования есть и сайты. Хотя, в целом, уклон на учётные системы, конечно.

Поэтому «все, используемые клиентом и написанные на языке 1С».

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

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

Это вообще к бесплатному софту относится…

Ядро Linux тоже бесплатное, и многие другие системные продукты - базы данных, те же веб-обозреватели. Вы всерьез думаете, что любая предложенная доработка неглядя - без модерации - добавляется в любые бесплатные продукты?) Тогда, как уже и было сказано выше, не имеет смысла продолжать разговор - пусть каждый остается при своем мнении.

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