Обьединенние линуксов во что-то более удобное, техничное и широкое

Ахах, извини. Да, я учусь только. Там еще в комментариях много кирпичей получается, сам читать бы устал.

Может не у всех сообществ получится создать общий устраивающий оба сообщества дистр, а вдруг у кого-то получится?

Не должно быть такого, что ты сделал микс или видео с поздавлением, тебе его скоро презентовать, а у тебя vlc еще собирается и будет собираться часов пять, т.к. сначала один раз, потом еще раз и т.д. Нужны предустановленные программы первоначально. Это главное. Затем, если хочешь скорости, пишешь что и как ты хочешь улучшить или какое у тебя железо и ОС пересобирает все под него, оставляя пакетные программы на случай сбоя или сборки. То есть если ты запорол что-то с флагами, ОС не кинет тебя, а просто придется использовать пакетную версию которая скачается быстро, либо предустановлена и она заиграет и засверкает. Места на диске для такого не жалко, мне кажется. А если что, можно удалить эти пакетные проги и использовать только прокомпилированные, коли очки на носу :) Или убрать возможность компилировать все под свою архитектуру и тогда все будет убунту-вэй оставаясь строгим и логичным.

То есть пока ОС компиляет, остается этакая возможно временная броня из пакетов. Можно сказать что это навроде одежды - она защищает тебя на всякий сложный случай навроде непредвиденной презентации.

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

Еще раз: это взаимоискдючающие понятия. Ну вот смотри: гибкость, когда много настроек. Простота - когда мало. Так сколько настроек делать: много или мало?

блочно меняющийся дистр-хамелеон

Мне кажется ты слабо понимаешь что такое дистр.
Если очень упрощенно, дистр - это пакетный менеджер. И всё. Программы в разных дистрибутивах не отличаются.
Если ты допускаешь альтернативы в програмах, зачем ты хочешь объеденить пакетные менеджеры? Это ж тоже программа.

Поэтому обьединение дистров должно начинаться с обьединения идей коммьюнити

Это не работает почти всегда.
Любые попытки начинания проекта с «объединения» людей обречены на провал. Рекомендую запомнить - столкнешься в жизни с такими ситуациями.
Начинать нужно с дела. Сначала нужен результат, хоть какой-то. Плюс - четкое видение, а не так «давайте придумаем». Только потом к тебе потянутся люди, и то, если сочтут твою идею разумной. Кстати, наиболее четко эта модель представлена на kickstarter, именно поэтому он так успешен.
Я уже молчу о том, что объеденить мало, самое сложное - управлять и преодолевать сложности.

... с их взаимопонимания и взаимопроникновения идей.

Это происходит постоянно. Это один из трех ключевых механизмов Open Source. Еще - форки и contribution.

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

Такой механизм уже есть. Правила пишут только для самых критичных вещей. Например, RAM и место на диске для firefox. Для остальных не имеет смысла на это тратить время.

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

Это делается легко. У меня есть. Могу дать рецепт.

Чтобы поставя на ночь компиляться, не переживать, вскакивая каждые два часа, а спокойно спать

Это уже есть: --keep-going

Это безумная идея: ты можешь регулировать на ходу необходимую гибкость. Менять ее при необходимости. Неплохо даже если только в сторону увеличения гибкости.

Вначале хотел описать теоретическую модель с идеальной негибкостью, где все предустановлено и само себя поддерживает, ничего нельзя изменить и юзер как бы шагами открывает для себя сам возможность более глубокой настройки. Но это много текста, сразу приведу пример более жизненный. Представим настройки убунту, вначале в ней все неплохо само по себе и малого количества настроек хватает. Кому-то этого хватит насовсем. Но, допустим, мне нужно поменять в системе что-то для чего не достаточно обычного меню. Я докачиваю пакет (патч), который расширяет мои возможности настройки графической среды. И я уже могу менять что-то в компизе или метасити. И та же программа, запускаясь, будет предлагать больше настроек. Так же с пакетным менеджером - вначале можно было просто скачать ту или иную программу, удалить то что ненужно, а захотев, докачал патч и пакетный менеджер научится, к примеру, работать уже с USE-флагами. Это как раз гибкость гибкости.

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

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

Возможно что в этой системе есть возможность смены пакетного менеджера одной строкой. Здесь основная суть не в том что при желании можно создать унылую систему в которой нет ничего нового и она только дублирует возможности других дистров, а Я не рассматриваю с позиций того что дистрибутивы как снежинки. Эту мою позицию можно описать как интуитивное ощущение возможности создания пакетного менеджера, обладающего свойствами необходимыми для негибкой убунту и гибкой генту. Для более понятного описания лучше опишу моделями. Можно представить apt-get как что-то привязанное к иксам наверху системы как расплывчатое пятно и еле-еле касается его дна. Работает быстро, но неглубоко. И эмердж, как расплывчатое пятно на дне,рядом с ядром, немного касающееся иксов. Или такая башня, которую строют с самого дна до верха. Работает медленно, но глубоко. И совместив свойства таких п/менеджеров, создав аналог первого, способный становиться аналогом другого можно добиться этакого адекватного столпа между иксами наверху и ядром внизу. Или хотя бы перехода от одного к другому. Первый тип неадекват потому что связи в системе меньше продуманы ближе к ядру, нет возможности ускорять систему и в ней сидят почти всегда люди неглубоко знающие систему. Другой случай плох тем что медленно растет из исходников, слишком глубок изначально и вызывает неприятие новичков(это плохое качество), отсекая доступ к адекватности.

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

В корпорациях(у конкурентов линукс) нет такого что проект делится на теоретическую часть, хорошо проработанную и практическую, с хорошим дизайном и в итоге эти две части не смогут сойтись. Там существует руководство, которое видя что две дополняющие друг друга части проекта не могут сойтись и предлагают решения, совершают свой хард ворк именно в этой области. Работа есть работа, она бывает разной в зависимости от задач. Может быть проект практический и технический, как подмести пол, а есть неочевидный поначалу и гуманитарный - поговорить с начальством о повышении зарплаты. Потому что могут не повышать зарплату или в должности если только хорошо делать работу. Проблема это всегда проблема какой бы она сложной и непонятной, абстрактной ни была. И соответственно имеет свое решение. Просто другие механизмы и инструменты. Вопрос в том, вижу ли я это один, что эти части нужно связывать. Будет ли это воспринято адекватно? Я же явно указываю на проблему разделенности, что из-за этого страдает качество софта и его адекватность у одних, конкурентноспособность у других, и в итоге мы все получаем плохую рекламу вне зависимости от дистра.

Будь такой дополняемый расширениями пакетный менеджер, разве не было бы возможным обьединение сообществ и его оздоровление? Сиди гентушник на одном дистре с убунтологом, допустил бы он чтобы раскладка у него начнет переключаться через полторы секунды, невозможность скачивания пакетным менеджером пакета или падение Firefox,не иметь возможности скачать файл с компьютера на флешку? Мне кажется что большее количество людей даст возможность кому-то уделять больле времени таким тонкостям настройки.

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

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

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

А есть ли другие способы решения моего затруднения без обьединения Линуксов?

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