Альфа-версия GoboLinux

Переписал новость получше, чем эта.

Интересен этот дистрибутив, особенно длина переменной $PATH.

http://storage9.static.itmages.ru/i/14/0122/h_1390406838_1803843_7467cbed32.png

От оно как! Я так и думал, что есть каталог с симлинками.

не нужно.Но длина этого долгово пути интересна.

А зачем нужен отдельный дистрибутив ради этой фичи, если эту фичу можно запилить поверх любого дистра ничего там не ломая? Аналогичным образом работает 0install, например. Подобную же фичу хотят запилить в Убунте — Click пакеты.

(Firestarter)

Название директорий с большой буквы вызывает отторжение.

А мне нравится подход в GoboLinux и MoonOS! Это верно, правильно дорогой идут товарищи!

С Макоси стянуто.

Но зачем оно?

Необходимо повторить путь трижды. Иначе не работает.

А я думал загнулся уже проект! Затея кажется бесперспективной, но показывает всю гибкость открытого софта.

Недо-Солярка, Недо-БЗДя, Недо-МакОСЬ, НЕдо-Линукс....и что это такое тогда?))

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

Udisksd и upowerd не запускаются автоматически DBus

Как им это удалось?

А в ней зачем? Ну понимаю в Windows, он регистронезависимый.

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

с ядром вместе?

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

Классная новость, я уже и не надеялся, если честно. GoboLinux - лучший концептуальный дистрибутив Linux!

О, восстание мертвецов!

Надо будет потыкать.

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

Ну, погоди!

Бинарный пакет Firefox собран с mozilla.org, но Firefox не может обновляться, поскольку нет соответствующих прав в /Programs.

вот ради этого стоило замутить дистрибутив

Polkitd тоже не запускается от DBus, а с терминала не запускается из-за проблем с правами.

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

Интересен этот дистрибутив, особенно длина переменной $PATH.

Там же симлинки.

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

GovnoLinux

УРАА!!!

Это for science.

Восставший из зада.

Название хорошее

А на лоре есть гобофаги?

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

А зачем?

Чтобы видеть все файлы от какой-нибудь проги в одном каталоге

которая полностью автоматизирована в плане установки.

Переписан графический установщик

А зачем нужен интерфейс, если все полностью автоматизировано?

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

Это Docker и это мега-круто.

очень странное желание - видеть файлы.

зомби воскрес

А зачем?

Ну может вот почему

1. чтобы софтины одна другой на ноги не наступали

2. чтобы можно было «установить» софт, просто скопировав его

3. легче проверить, не повредило ли что-то тот или иной пакет

4. /Programs звучит понятнее чем /usr/bin и т.д. Понятность с первого взгляда для новичков это хорошо.

5. если возможет пункт №2, то на «правильных» файловых системах можно копировать даже не файлами, а бинарниками, представляющими собой часть дерева директорий. Бинарники можно спокойно расшарить между виртуальными машинами, легко проверить их на сохранность, и т.д. Впрочем, для большинства народа это не актуально.

Чем-то напомнило Qubes (http://www.osp.ru/news/articles/2012/34/13017324/)

есть

чтобы софтины одна другой на ноги не наступали

Это задача пакетного менеджера. В нормальной системе установак одного пакета не перезаписывает файлы другого.

легче проверить, не повредило ли что-то тот или иной пакет

Это опять таки задача пакетного менеджера.

/Programs звучит понятнее чем /usr/bin и т.д. Понятность с первого взгляда для новичков это хорошо.

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

Тут просто все, они хотят, чтобы в систему можно было безболезненно пихать разнообразные версии софта без обновления всей системы и без всякого бэкпортирования. Windows стайл в Linux - все зависимости поставляются вместе с устанавливаемой программой. Но в винде все изначально под это заточено, а в лине в ситуации, когда порой для установки одного vlc требуется выкачать около 100 Мб зависимостей... А сколько всего в оперативке болтаться будет - вообще подумать страшно.

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

целью которого является реорганизация системных каталогов.

А зачем?

Ну что-бы подзасрать config.layout на пример.

Чтобы видеть все файлы от какой-нибудь проги в одном каталоге

А не проще ли ввести новый стандарт на размещение файлов приложения, вместо этих костылей?

Ну может вот почему

Вот мое мнение на сей счет:
Альфа-версия GoboLinux (комментарий)

В виде самостоятельного дистриба это не нужно. Нужны коллекции прикладного ПО для стабильных систем в виде магазина или как-то так.

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

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

А как оно работает с графическими приложениями?

А что, у них системные библиотеки тоже каждая в своей директории?

твой ник говорит о многом.

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

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