GoboLinux 015

просто удалив её директорию из /Programs.

а нельзя провернуть тоже самое используя директорию /opt ?

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

ЛОР-эффект.

А зачем тогда, собственно, /usr, /lib и прочее? Они тогда не нужны, а на место /opt пришёл /Programs.

Да не качайте же все сразу, охламоны! Вы ж им сайт положили.

Короче, сделали помойку как в винде.

Обоснуй.

Там те же самые Users, Program Files, System (в виде папке Windows). Не понимаю смысла данной затеи.

Чем это хуже /var, /lib, /home и т.д.?

В var логи, в lib библиотеки. А тут похоже все в одну кучу.

На opennet новость более подробная http://www.opennet.ru/opennews/art.shtml?num=39734

Взамен разбросанных по всем каталогам частей программ, GoboLinux хранит каждую программу в строго отведённом каталоге внутри логически разделённых системных директорий. Это хуже?

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

Автор, надо бы добавить подробностей о том, что нового в новой версии.

в lib библиотеки

все в одну кучу

Сделай ls /usr/lib и скажи мне, что это, если не куча.

Структура директорий напоминает оную в макоси.

После шести лет разработки

Иными словами.. не прошло и шести лет

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

Это нужно было делать в начале 2000-х, и были для этого все возможности, но кое у кого не было желания.

а что они делают с PATH?

а смысл?

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

они делают наподобие ln /Programs/mc/bin/mc /bin/mc

перекладывают труд пакетного менеджера на фс.

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

а чем, собственно, лучше? Практическое применение. Кроме утраивания объемов стореджа. То что можно удалить программу удалив 1 каталог - это неплохо, но у всех пакетов есть манифест который по yum/dpkg delete сделает тоже самое

корень состоит из директорий /Users, /Programs, /System, /Depot, /Mount и /Files

Интересно, мне одному это mac os напомнило?

Лет через 5 надеюсь увидеть это в Ubuntu. Это особенно гармонирует с их click-пакетами. Всё будет хорошо.

System, Programs, Users - всё верно, правильно логично. То как сейчас тоже нормально, то gobo-подход еще лучше!

Это то как в маке сейчас и сделано, и именно такой же подход они применили в плане сокрытия файлов из FHS.

Это напомнило Mac OS всем, кто имел с ней дело. Остальным это напомнило Винду. :D

Вообще, насколько Анонимус понимает, это не по Posix'у и не по FHS. То бишь не по стандартам.

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

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

круть мне нравиться, какая там система инициализации?

.... и именно такой же подход они применили в плане сокрытия файлов из FHS.

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

5 лет назад упоминание GoboLinux вызвало бы лютый-бешеный штром НЕНАВИСТИ Ведь на СВЯТОЕ, на FHS покусились, еретики.

гобосятина

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

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

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

Ооо! Отлично, надо заюзать на виртуалке!

В Debian нет проблем установить один и тот же пакет для разных архитектур, если он поддерживает multiarch.

Это хуже?

Чем-то лучше, чем-то хуже. Зато в нормальных дистрибутивах все маны в одном месте, все исполнимые файлы в другом и тд. Я не думаю, что это плохо, если у пакетного менеджера всё равно есть индекс.

Лет через 5 надеюсь увидеть это в Ubuntu

+100500

Почему оно не называется GoboNotLinux?

Используются статические библиотеки? Супер-идея.
Для таких случаев есть /opt

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

Если например вы работаете над 2 проектами. В каждом проекте есть текстовые файлы с комментариями и отчётами, код, графические файлы, бинарники как вы это всё будете хранить, так:

├── Project1
│   ├── bin
│   │   ├── lib2.so
│   │   └── lib.so
│   ├── img
│   │   ├── 1.png
│   │   ├── 2.png
│   │   └── 3.png
│   ├── src
│   │   ├── 1.cpp
│   │   └── 2.cpp
│   └── text
│       ├── results.txt
│       ├── task1.txt
│       └── task2.txt
└── Project2
    ├── bin
    │   ├── pr2.exe
    │   └── pr2.so
    ├── img
    │   ├── proj2.png
    │   └── zproj.png
    ├── src
    │   ├── main.cpp
    │   └── pr2_2.cpp
    └── text
        ├── proj2_task1.txt
        └── proj2_task2.txt

или так:

├── bin
│   ├── lib2.so
│   ├── lib.so
│   ├── pr2.exe
│   └── pr2.so
├── img
│   ├── 1.png
│   ├── 2.png
│   ├── 3.png
│   ├── proj2.png
│   └── zproj.png
├── src
│   ├── 1.cpp
│   ├── 2.cpp
│   ├── main.cpp
│   └── pr2_2.cpp
└── text
    ├── proj2_task1.txt
    ├── proj2_task2.txt
    ├── results.txt
    ├── task1.txt
    └── task2.txt

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

Вот именно, что если пакет поддерживает. О таких вещах должна думать система, а не создатель пакета.

Более того, конечному юзеру безразлично, как кто него там библиотеки с манами раскиданы.

Помойка это когда всё в /usr/bin и без костылей нужную программу нужной версии поставить невозможно.

Если например вы работаете над 2 проектами.

Ну одно дело свои проекты и другое дело программы.

Потому что это дистрибутив Linux.

Ну одно дело свои проекты и другое дело программы.

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

По тому, что тут написано, он не хочет быть линуксом.

Не работай в системных каталогах :}

Там те же самые Users, Program Files, System (в виде папке Windows). Не понимаю смысла данной затеи.

Модель, описываемая FHS, имеет смысл для удобного разделения файлов на исполняемые/не исполняемые, изменяемые/не изменяемые, что в некоторых случаях чрезвычайно удобно. Но для десктопа, чаще всего, такой подход не имеет особых преимуществ, скорее наоборот.

Конечно. Зашел я в /var/log - вот логи всех приложений, зашел в /bin - могу запускать нужную мне программу, а то и не одну. А тут что за фигня? Хочу удалить все логи - гуляй по каталогам, хочу конфиги забэкапить - гуляй по каталогам, ищи куда их распихали. Ерунда.

*Сабж не видел*