Подготовлен альтернативный репозиторий с исходными кодами Red Hat Enterprise Linux

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

В общем, это debian remix без собственной разработки.

Даже проще устроен, чем Artix. Там мультивыбор разных систем инициализации.

Это чем-то отличается от смысла моего сообщения: Подготовлен альтернативный репозиторий с исходными кодами Red Hat Enterprise Linux (комментарий)

?

В Devuan тоже возможен выбор инит системы (кроме собственно systemd) ?

Но преимущество Devuan в первую очередь в совместимости с большинством 3-rd party deb packages и инструкциями для Debian.

Т.е. по сути Devuan - это просто такой же Debian только без systemd.

В общем, это debian remix без собственной разработки.

Выпиливание systemd не подразумевает разработку отдельных небольших частей, если их нет готовых в Gentoo и т.п.?

Прокси это когда трафик идёт через промежуточный сервер. А тут не идёт - тут не прокси а редирект.

Прокси это когда трафик идёт через промежуточный сервер.

Это когда речь идёт об Internet Proxy, а не в общеупотребительном смысле:

proxy
  доверенное лицо 

А тут не идёт - тут не прокси а редирект.

https://dev1galaxy.org/files/amprolla.png

Или вот ещё пример:

Proxy Redirection Methods

So far, we have talked about general redirection methods. Content also may need to be accessed through various proxies (potentially for security reasons), or there might be a proxy cache in the network that a client should take advantage of (because it likely will be much faster to retrieve the cached content than it would be to go directly to the origin server).

But how do clients such as web browsers know to go to a proxy? There are three ways to determine this: by explicit browser configuration, by dynamic automatic configuration, and by transparent interception. We will discuss these three techniques in this section.

A proxy can, in turn, redirect client requests to a different proxy. For example, a proxy cache that does not have the content in its cache may choose to redirect the client to another cache. As this results in the response coming from a location different from the one from which the client requested the resource, we also will discuss several protocols used for peer proxy-cache redirection: the Internet Cache Protocol (ICP), the Cache Array Routing Protocol (CARP), and the Hyper Text Caching Protocol (HTCP). 

https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch20s05.html

И не выдёргивайте мои отдельные слова из контекста всей фразы:

Заменили своими пакетами с выпиленным systemd только около четырехсот оригинальных пакетов Debian из около 60K (общее количество пакетов в Debian), которые, как я понимаю, проксируются каким-то способом в первозданном бинарном виде прямиком из реп Debian.

Где говорится о том, что таки пакеты к пользователю поступают: «в первозданном бинарном виде прямиком из реп Debian».

Прокси это когда трафик идёт через промежуточный сервер. А тут не идёт

А позвольте тогда спросить, каким образом мой компьютер узнаёт, что пакет нужно качать с сервера Debian, если я указывал только репозиторий Devuan? Может быть, метаданные расположения пакетов таки приходят с сервера Devuan?

Метаданные (включая урл) - с devuan, сам пакет - с debian.

Ассоциация создателей-клоунов

По кривой дорожке Red Hat пошла.

IBM. У RedHat если и есть слово то только слово, как в IBM скажут так и будет.

Бесплатный сыр только в мышеловке…

В случае просрочки бывает и в мусорном контейнере.

бесплатно, без регистраций и смс

Не зря клоунов понаставили :)

Можно ли сборочный рецепт считать производной работой, это хороший юридический вопрос

Это уже давным давно явно прописано в лицензии:

complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable

https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

Под такое определение попадет Makefile и configure.ac.

А spec файл сборкой executable не занимается.

А то мы так далеко пойдем и под требование gpl всю билд-ферму подпишем, включая прошивку на Intel ME.

Мне от сервера приходит .deb, а в RHEL разве не rpm, а напрямую исполняемый файл? Так что лицензию я получаю к rpm, и, значит, её действие распространяется на скрипты для сборки из исходников вот этого rpm.

Ну вот и получается, что можно трактовать так, а можно этак.

Оракл будет готов в суде пободаться с IBM, если та решит закрыть спек файлы под проприетарной лицензией?

Оракл будет готов в суде пободаться с IBM, если та решит закрыть спек файлы под проприетарной лицензией?

Учитывая капитализацию компаний - ораклу будет проще поглотить ibm, чем «бодаться» с ней в суде :)

То есть ты считаешь, что количество миллиардов на этом уровне относительно IBM что-то решают?

Если оракль такой богатый, как ты полагаешь, то почему бы им не запилить все своё с нуля?

Есть, да, какая-то проблема?

То есть ты считаешь, что количество миллиардов на этом уровне относительно IBM что-то решают?

Но ведь в отношении с пиплсофт и с сан - зарешало ведь?

Если оракль такой богатый, как ты полагаешь, то почему бы им не запилить все своё с нуля?

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

Плюс есть еще альтернативные граждане во всяких роки и альмах-пальмах, которых можно использовать как негров на плантации. Свое еще писать после этого - ХА! :)

Есть, да, какая-то проблема?

Конечно, она звучит дословно: «нафига?»

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

Для оракла же своя ось это подложка под облако и среда для выполнения ждк - ну не прокатит с рхел возьмут дебиан или еще чего - придется раздувать бюджет на бодания в тендерах где рхело-специфичные штуки заложены или спекам надо соответствовать - это одна из двух очевидных причин выбора рхела (вторая слоган «у нас то же самое но за пол цены»).

Бонусом - У оракла уже была (и есть по инерции) полностью подконтрольная ось (Солярис) - она оказалась не особо нужна для продажи своих решений, и кстати она до сих пор поддерживается и одновременно открыта (как минимум в виде форка)

и кстати она до сих пор … и одновременно открыта (как минимум в виде форка)

Это заслуга Oracle ? :)

Мне от сервера приходит .deb, а в RHEL разве не rpm, а напрямую исполняемый файл? Так что лицензию я получаю к rpm,

Где в GPL лицензии написано, что нужно открывать сорцы софта, который не линкуется с GPL-ным софтом?

Скрипт твоего RPM пакета самостоятельно делает вызовы либ какого-нибудь GPL софта? Нет? Тогда почему нужно открывать этот скрипт?

и, значит, её действие распространяется на скрипты для сборки из исходников вот этого rpm.

RPM пакет - это блоб, но сам он не вызывает никакого GPL софта через функции? Блоб, аналогичный ZIP или JPG файлу?

Смотря, что есть rpm:

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

И если rpm - это просто архив, то тогда не понятно, почему придрались к тому, что по spec создаётся rpm, если по сути по spec собирается бинарник с патчами, а стадия упаковки/архивирования вообще не важна при рассмотрении вопросов лицензирования. И, таким образом, лицензия GPL распространяется на spec.

Оракл будет готов в суде пободаться с IBM,

У них сейчас уже руки на кольтах и пристально смотрят друг на друга (образно выражаясь). С одной стороны IBM своей EULA ограничил права по GPL. С другой стороны, пострадавших (пока) нет(?), т.е. права де-факто не ограничены, GPL соблюдена. И даже когда появится пострадавший, то нельзя будет доказать, что договор был разорван именно по причине публикации энтерпрайз-исходников, а не по какой-либо другой, включая «просто, клиент надоел». Причём, именно этому первому пострадавшему будет больно, что уже уменьшает вероятность его появления. Потом будет второй, третий. Им тоже будет больно. Ну, совпадения. Потом четвёртый, пятый. И вот тут (другая противоборствующая) империя наносит ответный удар. Потому что когда договор уже разорван со множеством клиентов, которые как раз накануне воспользовались правами по GPL и открыли исходники, то тут есть очень очевидное подозрение, что де-факто GPL нарушена. Да де-юре их не ограничивали. Но если обнаруживается очевидная зависимость между использованием прав по GPL и разрыванием контракта - то де-факто тут ограничение и нарушение.

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

А зачем все эти партизанские изыскания, когда Red Hat IMHO может в явном письменном виде официально написать, что:

1. Мы предоставили вам доступ к RHEL v8.8, как и написано в договоре подписки.

2. Вы воспользовались своим правом прекратить этот договор подписки за счёт реализации вашего права по пункту такому-то публично форкнуть RHEL v8.8

3. Мы ценим условия нашего с вами договора подписки, уважаем ваши права, и потому очень рады предоставленной вам возможности форкнуть RHEL v8.8, после чего, как и договаривались, отключаем вашу учётную запись (чтобы, не дай Бог, не обидеть вас несоблюдением условий нашего договора подписки) и будем рады оплате вашей новой подписки под новой учётной записью.

С нетерпением ждём вашего возврата к нам, с наилучшими пожеланиями ваш Red Hat! :)

Где тут нарушен GPL?!

И ессно им за это ничего не будет.

Вы воспользовались своим правом прекратить этот договор подписки

Нет, я не желал прекращать этот договор, воспользовавшись предоставленными мне правами по GPL.

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

Нет, я не желал прекращать этот договор, воспользовавшись предоставленными мне правами по GPL.

Почему тогда подписал договор подписки, если не желал?

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

Так разве такой пункт незаконный? Докажи сначала его недействительность.

Это заслуга Oracle ? :)

Ассоциации тыкателей в труп сана.

просто, клиент надоел

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

Какие недостатки у нынешнего SmartOS по сравнению с Oracle Solaris кроме поддерживаемых железок (только x86)?

Какие недостатки у нынешнего SmartOS по сравнению с Oracle Solaris кроме поддерживаемых железок (только x86)?

А какие у него должны быть недостатки? :D

Я, честно, не тыкал ничего кроме индианы, но основная логика соляроклонов сейчас это легаси-ждк (ввиду того что новые ждк внезапно (с) не поддерживают соляру) и труЪ зфс (ради чего ее оракл в оригинале еще и держит)

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

SmartOS - это IMHO в первую очередь LX zones для контейнеров и виртуалки bhyve.

ZFS в Illumos наверно тоже понадежнее при аппаратных сбоях, чтобы без сюрпризов типа подвисаний пула (происходит чёто ужасное, pool busy resilvering или temporary unavailable) заменить устройство без необходимости ребутать хост просто ради переимпорта отвисшего пула?

Хотя очень редкие проблемы с аптаймом ZFS на Linux, наверно, решаются кластерной FS или даже кластерным блочным устройством типа Linstor DRBD поверх ZFS?

виртуалки bhyve

Признаться честно, не понимаю зачем их тащить при возможности переноса на квм

ZFS на Linux

А вот тут наоборот - понимаю как тех кто считает что он не готов так и тех кто не понимает зачем переносить с соляры/бсд на zfsol

Признаться честно, не понимаю зачем их тащить при возможности переноса на квм

По отзывам Illumos понадежнее в долгосрочном плане при длительном uptime.

IMHO Linux через 3-6 месяцев нагруженного аптайма становится сильно неповоротливым и как бы резиновым в плане реакции на те или иные запросы. Даже команды CLI типа zfs list -t snapshot. Толи у него память сильно фрагментируется, толи какие-то утечки особенно в ядре и вероятно дровах оборудования. В общем семь бед - один ресет. С вендой это происходит обычно в разы, а то и десятки раз быстрее и с более печальными последствиями не просто просадки производительности, но и даже отказом в обслуживании тех или иных сервисов.

При использовании HA вероятно это не сильно критично, но для standalone хостов или маленьких кластеров типа master-slave лучше всё же не допускать ребутов лишь только из-за их длительного аптайма.

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

Кроме того на базе SmartOS есть Elastic Docker Cluster (линк у меня в профиле). Т.е. это Docker API для запуска Linux контейнеров OCI в LX zones многонодового кластера SmartOS. Можно использовать с docker-compose и т.п.

но для standalone хостов или маленьких кластеров

Допустим аптайм в условные 99.5% т.е. для 6 месяцев это между делом 22 (!) часа простоя :D
А если два часа за пол года то это уже 99.95% - выше норм HA

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

Если оракль такой богатый, как ты полагаешь, то почему бы им не запилить все своё с нуля?

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

Оракл в своё время прилично так вбухал в собственные средства разработки. Но получилось, в общем, так себе (если что, я говорю, как человек, который на ЭТОМ писал, к счастью, не очень долго). Потом это дошло до самого Оракла, они купили Sun и стали хозяевами Java. А свои самобытные Oracle Developer и Oracle Designer забросили.

Звучит так, как будто Шапка, это пьяный матрос.

Лучше поздно, чем никогда. Но я морально уже созрел переползать на Debian.

Однако, качество RHEL дистрибутива исторически было выше, добротнее.

т.е. GPL не работает в данном случае?

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

Если оракль такой богатый, как ты полагаешь, то почему бы им не запилить все своё с нуля?

Оракел сейчас вкладывает в разработку ядра и разработку собственного дистра больше, чем шапка вкладывает в ядро и свой дистр. Так что тут не желание халявы, как некоторые выше накалякали. Для оракела его дистр был всегда нужен прежде всего ему самому: специализированные железки (Ларри такие любит), разработка и поддержка продаваемого софта, а с недавнего времени еще и облако, которое стало для оракела курицой с золотыми яйцами. Оракел вообще с конца девяностых очень сильно линуксовая компания. Почему же не пилят свой дистр с нуля? В одном месте у оракела написано: чтоб не плодить зоопарк и разброд в линуксе, решили мы сделать свой дистр бинарно совместимым и идентичным с одним из принятых в корпоративном мире опенсорсных флагманов. И я лично тут оракелу верю, и поддерживаю. Желание создавать свои неповторимые болгеносы есть только у ЧСВ-шников и бездельников, которые и являются виновниками того зоопарка дистров линукса

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

Не вопрос, CentOS Stream всячески совместим с флагманом – бери и делай, но нет, они устроили весь этот цирк.

CentOS Stream всячески совместим с флагманом

CentOS Stream не совсем совместим с релизами rhel для корпоративного использования. Centos stream-это тот самый зоопарк и разброд, который устроила уже шапка. В целом у меня складывается впечатление, что это не оракел запилит свой уникальный линукс, а шапка сделает свой rhel настолько уникальным, что окажется с ним где-то на обочине. Оракел же, и все кто примкнули к идее, будут держать марку того самого флагманского опенсорсного линукса для корпоративного мира, на который пересядут все корпорации со временем.

Если чего и смогут добиться эти GPL-тролли, так это того, что все корпорации пересядут на убунту.

Ассоциация создателей клонов Red Hat Enterprise Linux

ЛОЛкнул

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

Вы видимо с Ораклом не общались если в сказки верите.