Совмещение всех достижений (униварсальный дистр)

[zgr]

Возможно ли создание одного дистрибутива линукс который включал бы все достижения компаний занимающихся продвижением этой системы (то есть дистра в котором были бы и portage, nptl, yast, apt-get, mono...)

[Bruce]

нет )

[mark]

он был бы неработоспособен вообще :P

[Pieron]

Возможно ли создание одного дистрибутива линукс который включал бы все достижения компаний занимающихся продвижением этой системы (то есть дистра в котором были бы и portage, nptl, yast, apt-get, mono...)

Дык создай
Берешь и доводишь lfs до необходимости.... если времени и терпения хватит

[diesel]

Возможно ли создание одного дистрибутива линукс который включал бы все достижения компаний занимающихся продвижением этой системы (то есть дистра в котором были бы и portage, nptl, yast, apt-get, mono...)

а зачем?

[polachok]

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

/usr/bin/emerge
#!/bin/sh
apt-get install $1

[nerezus]

А зачем Кубунте нужен Яст?

[призрак коммунизма]

он был бы неработоспособен вообще :P

Почему неработоспособен? что тормозом была то 100 пудов!

[Slimy]

Наверное автор имел виду другое. Он имел виду выбор сырцовой системы и прекомпилированой для ондонго дистрибутива т.е. пакет ставлся в зависимости от желания, возможностей и времени пользователя. Чтож это бы ло бы круто, но кто такое сможет создать? Или это предложение сделать "еще один дистрибутив"? . А может имелась виду не только система пакетов а объединение всех зравых и удачных идей со всех дистрибутивов в один? Да это была бы супер система но кто ее сможет сделать.
А может просто имелось виду совместимость системы с разными видами распространения софта принятыми в дистрибутивах это и впрямь не возможно из-за зависимостей т.к. получится просто монстр с библиотеками на все случаи жизни( хотя если учесть факт что большинтсво дистрибутиво-особенных зависимостей обусловленны программамив которых потребность в одних и тех же функциях то проделав огромнаю работу может быть чтото и выйдет.), но даже если и выйдет то получится, что самым популярным видом пакетов будет - нативный для этой системы вид, т.к. многие захотят такую систему в которой все самое вкучное из мира Open Source.
В общем что хотел сказать автор? А вообще идея единого дистрибутива думаю что не нова, но физически не возможна, например как примирить RED HATE и Novell ведь linux это еще и бизнес.

[zenwolf]

А зачем Кубунте нужен Яст?

видимо за тем же что apt-get для Suse

Возможно ли создание одного дистрибутива линукс который включал бы все достижения компаний занимающихся продвижением этой системы (то есть дистра в котором были бы и portage, nptl, yast, apt-get, mono...)

я тебе открою страшную тайну ,этот дистрибутив уже есть ,и ты на нём сидишь кстати

[Лис]

видимо за тем же что apt-get для Suse

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

[zenwolf]

видимо за тем же что apt-get для Suse

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

дык и я про тоже ,иносказательно правда

[diesel]

Наверное автор имел виду другое. Он имел виду выбор сырцовой системы и прекомпилированой для ондонго дистрибутива

И для этого нада создавать дистрибъютив? - Чего люди не сделают ради того чтобы не читать документацию к apt (или emerge).

[alv]

Наверное автор имел виду другое. Он имел виду выбор сырцовой системы и прекомпилированой для ондонго дистрибутива

И для этого нада создавать дистрибъютив? - Чего люди не сделают ради того чтобы не читать документацию к apt (или emerge).

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

[zgr]

А может имелась виду не только система пакетов а объединение всех зравых и удачных идей со всех дистрибутивов в один? Да это была бы супер система но кто ее сможет сделать.

Именно!!! Возможно ли это на правовой основе?
apt-get, yast я просто так написал, я не говорил о кубунте с ястом!

[alv]

А может имелась виду не только система пакетов а объединение всех зравых и удачных идей со всех дистрибутивов в один? Да это была бы супер система но кто ее сможет сделать.

Именно!!! Возможно ли это на правовой основе?

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

[diesel]

А может имелась виду не только система пакетов а объединение всех зравых и удачных идей со всех дистрибутивов в один? Да это была бы супер система но кто ее сможет сделать.

Именно!!! Возможно ли это на правовой основе?
apt-get, yast я просто так написал, я не говорил о кубунте с ястом!

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

[zenwolf]

А может имелась виду не только система пакетов а объединение всех зравых и удачных идей со всех дистрибутивов в один? Да это была бы супер система но кто ее сможет сделать.

Именно!!! Возможно ли это на правовой основе?
apt-get, yast я просто так написал, я не говорил о кубунте с ястом!

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

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

[diesel]

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

ну ведь крутилось же что-то в мозгу автора темы что побудило его создать тему - либо проблемы какие-то с уже существующими пакетными менеджерами, либо ... ХЗ ... собственные какие идеи по поводу того как бы было круто ...

[Лис]

либо проблемы какие-то с уже существующими пакетными менеджерами

Опять же, не было бы rpm, apt, tgz, наконец, если бы не было множества мнений.

[Skull]

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

Да идеи одинаковы. Разница - в реализации и её тормозах. Однако пока дистрибутива с грамотным пакетным менеджером нет и не предвидется.

IMHO, идеальная пакетная дистрибуция - autopackage. Эх, если бы появились мэйнтейнеры репозитория для него... В таком случае программу будет поставить на любой дистр также просто как EXE под Windows - но без идиотских диалогов.

[alv]

Однако пока дистрибутива с грамотным пакетным менеджером нет и не предвидется.

ИМХО как раз наоборот, их много
только вот каждый грамотен по своему

IMHO, идеальная пакетная дистрибуция - autopackage.

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

[Portnov]

Я пару прог из autopackage ставил на пару разных машин. Оч даже ничего. Все свои зависимости само же и выкачивает.

[Slimy]

Что касается идей то не стоит зацикливатся только на пакетах. Например у одних дистрибутивов ядра работают удачнее и стабильнее чем у других. Конфигураторы юзер френдли, автомонтирование и т.д. маленькие вкусности которые вроде бы не приметны но делают работу удобнее.
Хотя вот например я знаю две вещи которые не умеет ни один из извесных мне менеджеров Linux (1) при выборе пакетов учитывать аппаратные возможности 2) удалять те пакеты которые стояли только для удовлетворения зависмостей основного(требуемого пользователю) пакета после его удаления).
или если по думать то идея сыркового и прекомпилированного дистрибутва одновременно допустим на диске с системой каждой твари по паре( сырцы и готовый бинарный пакет) и пользователь еще на этапе инсталяции системы выбирает какой пакет как ему поставить (например для ядра это былобы очень полезно) а обо всем остальном заботится система, удобство в том что при необходимости пользователь может бысто развернуть систему либо иметь пакеты собранные под себя с подержкой того что действительно нужно получится некий сплав portage и RPM . конечно можно и в rpm дистрибутивах собирать из сырцов, но вряли это также удобно как в исконно сырцовых системах, и при установке всеравно нельзя.
В общем идей можно много насобирать и придумать всеравно толку не будет.

[zenwolf]

Однако пока дистрибутива с грамотным пакетным менеджером нет и не предвидется.

ИМХО как раз наоборот, их много
только вот каждый грамотен по своему

IMHO, идеальная пакетная дистрибуция - autopackage.

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

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

[serzh-z]

2) удалять те пакеты которые стояли только для удовлетворения зависмостей основного(требуемого пользователю) пакета после его удаления).

Как минимум один умеет это - Portage.

[Skull]

Однако пока дистрибутива с грамотным пакетным менеджером нет и не предвидется.

ИМХО как раз наоборот, их много
только вот каждый грамотен по своему

Слишком замороченные и тормозные. Проблема и в реализации и политике дробления.

IMHO, идеальная пакетная дистрибуция - autopackage.

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

Мало пакетов. Я inkscape ставил - работает. Сейчас autopackage не использую, зато часто использую klik. Идея та же, но пакеты старые до ужаса, поскольку внутри у неё - Debian.

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

Что-то я в стабильности разницы не замечал.

Конфигураторы юзер френдли, автомонтирование и т.д. маленькие вкусности которые вроде бы не приметны но делают работу удобнее.

Тык различаются только фронтэндами да конфигурациями. А так используется тот же набор софта.

Хотя вот например я знаю две вещи которые не умеет ни один из извесных мне менеджеров Linux (1) при выборе пакетов учитывать аппаратные возможности

Насколько я знаю, ядро ставится адаптированное под текущий процессор. А что ещё?

2) удалять те пакеты которые стояли только для удовлетворения зависмостей основного(требуемого пользователю) пакета после его удаления).

В apt вроде есть удаление пакетов-сироток. Для RPM написать такой скрипт недолго. Но при современном объёме дисков - не нужно.

...пользователь еще на этапе инсталяции системы выбирает какой пакет как ему поставить (например для ядра это было бы очень полезно)

Ну не знаю, ядро пересобирал один раз лет 5 назад для Oracle. Не актуально это на современной технике.

[t.t]

В apt вроде есть удаление пакетов-сироток.

↑

В apt есть не только это. Кстати, после вашей фразы о том, что идеального менеджера пакетов не существует, можно вопрос? Конкретные свойства, которых не хватает существующим менеджерам пакетов, по пунктам?

Для RPM написать такой скрипт недолго. Но при современном объёме дисков - не нужно.

↑

Да-да, совсем не нужно. Несколько сот метров хлама -- кого это волнует?.. Правильный ответ: кого волнует, тот работает в не-RPM дистрибутивах ;-)

[diesel]

...пользователь еще на этапе инсталяции системы выбирает какой пакет как ему поставить (например для ядра это было бы очень полезно)

Ну не знаю, ядро пересобирал один раз лет 5 назад для Oracle. Не актуально это на современной технике.

Дебиан позволяет выбирать ядра на этапе инсталяции в режиме expert.

[Slimy]

Что-то я в стабильности разницы не замечал.

А я замечал. Ставлю SUSE загрузка тормозит минут на 20, при перезгузке системы сразу после grub там где должна быть загрузка ядра проиходит перезарузка машины и так до бесконечности, но стоит вырубить питание (хоть на секунду) после этого первый запуск такого глюка нет. Чего я только не пытался делать даже ядро от slick поставил и часть вроде с некоторыми опциями ожило, но тут недвано опять заглючило. Поставил на тоже железо Ubuntu 5.10 ( с халявных дисков)все как часы безовсяких плясок с бубном. Про ALT я упомниать вообще не буду наэ том железе (там сети не было и не предвиделось). Вот вам и примеры. Причем тут явно виновато ядро и acpi. А исходники вроде все тырят с kernel.org а как разнятся результаты.

Тык различаются только фронтэндами да конфигурациями. А так используется тот же набор софта.

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

В apt вроде есть удаление пакетов-сироток. Для RPM написать такой скрипт недолго. Но при современном объёме дисков - не нужно.

Ну про deb я мало что сказать могу, только недавно с ним знаком, но порадовало то что на этапе инсталяции возможны вопросы по конфигурации устанавливаемого пакета в RPM такого ни разу не видел. С apt еще тоже не очень знаком например был шокирован когда на apt-get install mc сказали что такого нет, update тоже не помогло. И этот самый apt удаляет сам сирот не спрашивая или его тырнут на это руками надо?
Вот еще вопрос зреет если скрипт написать не долго и не сложно, почему же его тогда штатно не прикрутили к дистрибутиву вроде костыля.

Да-да, совсем не нужно. Несколько сот метров хлама -- кого это волнует?.. Правильный ответ: кого волнует, тот работает в не-RPM дистрибутивах ;-)

меня вот например волнует сей вопрос, но кудаже деться от RPM если в моем дистрибутиве RPM only

Как минимум один умеет это - Portage

Я очень рад что там все так круто

Дебиан позволяет выбирать ядра на этапе инсталяции в режиме expert.

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

Ну не знаю, ядро пересобирал один раз лет 5 назад для Oracle. Не актуально это на современной технике.

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

Насколько я знаю, ядро ставится адаптированное под текущий процессор. А что ещё?

например не ставить железоспецифичный софт когда такого железа нет. Для примера подежка модема и ISDN если их у меня нет нафига мне этот софт да еще и конфигураторы к нему? Или софт для tv тюнеров (ставится с каждой кде не поинтересовавшись есть ли физическая возможность для него)также bluetouch и т.д. В общем конфигураторы есть, софт есть, а устройства нет, только с толку пользователя сбивает(поверте найдутся и такие которые подумают что раз эта штука(софт) есть значит в компьтере появилась реальная возможность использовать допустим bluetouch без наличия физически такого устройства).
P.S.Только не надо тут оправдывать этот недочет тем что мало места пакеты эти занимают.