Состоялся релиз MoonOS

А вот последняя версия дистрибутива датируется 30.03.2008, так что да, похоже, что умер.

Чем очередной болгенос лучше оригинала?

пишут на инглише, но так безграмотно, что даже читать неприятно

If you use exists home partition...

если вы используете существует домашний раздел

/home mountpoint will be not work...

точка монтирования /home будет нет работать

moonOS has it own File Hierarchy System...

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

Вырвать бы педали этим спортсменам.

Если тебе нечем заняться посылай патчи в апстрим. Они специально энтропию повышают или им действительно нравится делать «свой дистрибутив»?

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

Не во всех командах есть хорошие переводчики на английский язык. Понять в принципе все что написанно там можно, в самой системе корявых переводов не заметил (от бубунты они как понимаю). MoonOS разрабатывается при мягко говоря меньших вливаниях средств нежели та же бубунта. А язык сайта думаю был выбран этот лишь для того, чтобы охватить как можно больше людей. Да и говорят\пишут большинство людей далеко не на идеальном и правильном английском. Знаю по личному опыту выезда в арабские страны те же.

А за что? За то, что люди делают то, что им нравится? Кто знает - может именно такая вот маленькая команда разработчиков в конечном итоге сделает из Linux коммерческий законченный для рядового пользователя продукт, который встанет в один ряд с продукцией Microsoft и Apple?

Как бы никто не заставляет использовать вместо «бубунты» - «мунось», не нравится - не ставьте, дело ваше. Но прежде чем критиковать людей, которые все же уже 4-ую версию дистриба релизят (причем не просто с новой шкуркой, т.е. не сборку, а именно дистриб свой делают) - сделайте что-то подобное или по крайней мере не поливайте грязью за глаза. На ЛОРе очень просто это сделать. Напишите в чем "-" дистриба разработчику к примеру.

еще один лисапед. ненужен.

Сколько еще мы увидим велосипедов! Может хватит?

Съешь-ка галоперидольца.

Если тебе нечем заняться посылай патчи в апстрим

Можно я лучше буду посылать подальше таких советчиков? Ну пожалуйста!

Раньше это был один из немногих дистров на энлайте.

А сейчас вообще растворился среди сотен остальных клонов.

> говорят\пишут большинство людей далеко не на идеальном и правильном английском. Знаю по личному опыту выезда в арабские страны те же.

Раскрой мысль. Когда это арабские страны стали хорошим местом для поиска идеального и правильного английского?

<fat>Обратный слэш как бы намекает...</fat>

>Для тех кто считает что это дистрибутив один из сотни одних и тех же на базе Ubuntu - вы ошибаетесь.

Просвяти. Кроме фс, фаензыы и обой ничего не вижу.

Тут объяснять ничего не надо. Они клепают свои велосипеды с овальными колесами в надежде что кому то так больше понравится. И ведь действительно, многим нравится. Но вот сдохнет Убунта и сразу прокатится волна смертей ее клонов. Брать пакеты из дебиана и доводить до состояния Убунты они не смогут и уж тем более до уровня МунОС. Отсюда вывод, что все халявщики которые постоянно на подсосе - не нужны, как и сама Убанта которая 3/4 пакетов тянет из Дебиана. Ни один дистрибутив невозможно допилить и угодить всем. Всегда будут недоделки и одним будет нравиться, а другим нет. Нужно иметь один .deb-based, один rpm-based и один source-based, остальные сжечь и никому плохо не станет. А завлекать хомячков с помощью «киллер фич» и новых нескучных обоев это значит скатить любой дистрибутив в Убунту. Если количество и качество драйверов под Linux будет напрямую зависеть от вновь прибывших оглоедов, то я не против, пусть забирают и что угодно делаюn со своей Убунтой. Мне не жалко, главное чтоб дрова писАлись.

>Можно я лучше буду посылать подальше таких советчиков? Ну пожалуйста!

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

> сделает из Linux коммерческий законченный для рядового пользователя продукт, который встанет в один ряд с продукцией Microsoft и Apple

Не нужен. Уже есть «продукция Microsoft и Apple», берите и пользуйтесь. Это маразм какой-то: пытаться сделать из GNU/Linux продукт _худшего_ качества и гордиться этим.

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

Классическое спервадобейся, а также 4.3. По существу-то есть что сказать?

> причем не просто с новой шкуркой, т.е. не сборку, а именно дистриб свой делают

Так опишите же ключевые свойства дистрибутива. На сайте — ноль информации. В этом треде — ноль информации. Телепаты еще не очухались после праздников, так что ничем помочь не могут. «Многочисленные улучшения» можно запилить в свой репозиторий, чтобы любой пользователь deb-based системы мог ими воспользоваться. А не велосипедить для этого свой дистрибутив.

Что еще остаётся — своя «принципиально новая» FHS? О ней нет ни слова, так что трудно судить, что это такое. Но есть подозрение, что просто очередная попытка надругаться над стандартом, обозвав все каталоги в MacOSX-стиле. Без понимая сути, какие реально недостатки заключены в существующей FHS, и почему она требует модернизации. Культ карго как он есть.

Между тем, ключевая мысль при разработке GoboLinux была такова: файловая система в роли менеджера пакетов. И раз вы выше писали, что в MoonOS иерархия каталогов «приближена к Gobo» то возникает закономерный вопрос: нафига ежу футболка нафига в deb-based системе велосипедить ФС «как в Gobo», если в ней уже есть пакетный менеджер? Либо трусы наденьте, либо крестик снимите.

Школьные каникулы 2010-2011 учебного года: зимние - с 27 декабря 2010 года по 09 января 2011 года. Ясно.

>Школьные каникулы 2010-2011 учебного года: зимние - с 27 декабря 2010 года по 09 января 2011 года.

Спасибо за информацию.

> Просвяти. Кроме фс, фаензыы и обой ничего не вижу.

Новая иерархия файловой системы;

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

А ты мне, наверное, запретишь своими гневными постами? :)

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

Отсюда вывод, что все халявщики которые постоянно на подсосе - не нужны

Аргумент про то, что разработчики не работают с апстримом прогнил, наверное, еще в прошлом веке. И употребляют его, как правило, те, кто не знает механизмов функционирования сообщества. Безотносительно дистрибутива.

Нужно иметь один .deb-based, один rpm-based и один source-based

Кому нужно? Количество клонов и деривативов - прямое следствие каноничных трех свобод софта. От этого не избавиться, хоть ты десять гневных постов оставь. Альтернатива этому - известно что. GTFO.

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

Не неси чушь, ты вроде взрослый человек.

Это можно засчитывать как слив? Или ты просто не можешь придумать обоснования своей авторитарной позиции «ололо, не нужно, делайте как я сказал, сучечки»? :)

> Новая иерархия файловой системы;
wut?

Многочисленные улучшения по сравнению с Ubuntu 10.10.

Маркетологи коллапсируют в экстазе.

Красивый дистр. +1 к выбору диструбутива с набором из коробки на основе любимой бубунты

И кстати у них только что сайт повалился....

> И кстати у них только что сайт повалился....

ЛОР-эффект, видимо.

Готов он уже пару лет как. Народ просто привык жрать кактус,плюс несколько специфичных вендософтин. У меня несколько знакомых перешли на Убанту и агитируют окружающих (полёт нормальный примерно по пол года и более, вечно хворающую форточку вспоминают с ужасом, некоторые держат в дуалбуте для 1-2х редко используемых узкопрофильных софтин). Да иерерхия фс им по большей части до лампочки. Тем кто за это время сполз с Убанты на что потруёвее FHS тоже не жмёт.

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

Для лёгкого переноса и развёртывания софта есть статическая сборка (да и в макоси она же, вроде, и в форточках тем более). Распаковал->запустил->PROFIT! Это уже здесь и уже работает. Можно добавить немного инфраструктуры, типа репозиториев, модулей fuse для чтения архивов, etc. для _ВСЕХ_ основных дистров.

Вобщем не смотрел но осуждаю, т.к. не вижу аргументации за ломку FHS, а вижу только сопли про «кавайный как Яббл» дистрибутив.

Может лучше попробуйте объяснить зачем опять ломают FHS? «Вот в Макоси!» - не объяснение.

Убунтоидные деривативы такие унылые.

>FHS

FHS это тоже помойка, ничем не лучше, чем в окошках. Программы как сопли размазаны по всей файловой системе, для управления ими приходится использовать всевозможные костыльные pacman-ы, rpm-ы и прочую чушь. Вместо того, чтобы юниксвейно возложить эти обязанности на уже существующие средства системы: саму файловую структуру, набор стандартных утилит и простые текстовые конфиги. А поскольку FHS —стандарт, и совместимость с ним так или иначе требуется тащить дальше, то структуру ФС необходимо виртуализовать. Именно это пытались сделать в Gobo, но первый блин пока вышел комом.

Для лёгкого переноса и развёртывания софта есть статическая сборка

Это костыль.

Может лучше попробуйте объяснить зачем опять ломают FHS

Потому что могут.

А если серьезно - я не знаю, зачем это нужно.

костыльные pacman-ы, rpm-ы и прочую чушь

Для лёгкого переноса и развёртывания софта есть статическая сборка

Это костыль.

Ну и каша. Попробуешь обосновать?

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

Как именно cама файловая структура, набор стандартных утилит и простые текстовые конфиги помогут мне обновить десяток машин в автоматическом режиме?

>Ну и каша. Попробуешь обосновать?

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

По существу, что такое приложение. Это просто набор ресурсов: исполняемых файлов, библиотек, файлов данных, путей к пользовательским или системным настройкам, логам и так далее. Пространство имён. И сейчас это пространство имён одно на всех, и оно жестко связано непосредственно со структурой каталогов на носителе: FHS. Оно требует виртуализации. Если мы будем динамически формировать это пространство имён и разработаем единый формат для описания импортируемых/экспортируемых ресурсов, решится множество проблем:
* Исчезнет разница между «флешечными» и «пакетными» сборками программы.
* Установка и удаление пакетов сведётся в 90% случаев к распаковке/удалению подкаталога где-нибудь в /share/packages/ или подобном.
* Пространств имён может быть больше одного. Они могут быть разные у разных программ, у разных пользователей, у разных сеансов и т.п. Как угодно. Одни пространства имён могут быть построены на основе других. У нас есть chroot, симлинки и т.п., вот только мы ими либо совсем не пользуемся, либо каждый раз выполняем восход солнца вручную. А надо автоматизировать.
* Файловая система сама служит базой данный установленных пакетов. Кучи мусора в /var, служащие только для того, чтобы помнить, что установлено в системе — не нужны. Принцип DRY — хороший принцип.

Как именно cама файловая структура, набор стандартных утилит и простые текстовые конфиги помогут мне обновить десяток машин в автоматическом режиме?

bash в помощь. Серьёзно, речь не о том, чтобы избавиться от пакетных менеджеров как класса, а о том, чтобы поставить их на правильное место в системе: как простой обёртки для скачивания/сборки программ и распихиванию их по каталогам.

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

На счёт пространств имён в целом согласен, но писать на коленке свой APT с ... и ... не охота. А если использовать чужой, то разницы особой нету. В «кучах мусора в /var» хранится гораздо больше информации, чем просто список установленных пакетов. man debsums например. БД с этими данными всё равно лишней не будет.

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

В данном обсуждении несколько раз упоминался запуск программ прямо из архивов в Макоси, я так понял что ЛуньОС пытаются заточить под это же? В чём принципиальное отличие такого подхода от статических сборок/таскания библиотек с собой? Чем это ближе к описанным Вами пространствам имён (идея прямо скажем интересная, я джва года такое хочу в своём дебиане)? Тем более уже есть средства автоматизации работы с чрутами, чем лунный подход правильнее, кроме того что многое от него сломается?

>Принцип DRY — хороший принцип.
Про KISS тоже забывать не стоит =)

>Ваш вариант взаимодействия софта с системными библиотекаи

Для начала, сформулируйте, чем «системные библиотеки» отличаются от «несистемных».

без раскладывания библиотек по предусмотренным для этого местам

Вы, видимо, по диагонали читали, что я писал постом ранее. Именно о эмуляции раскладывания по предусмотренным для этого местам я и пишу.

Библиотека — всего лишь файл, который должен при запуске приложения быть виден процессу по определённому пути в системе. И никакой магии тут нет.

Если программа A хочет видеть библиотеку libastral.so, то мы ей и дадим /usr/lib/libastral1.so, не важно, где физически при этом она находится: в /usr/share/packages/libastral/, в ~/packages/libastral/, в /media/флешка/libastral/ или еще где. А если программе B нужно предоставить libastral.so, но с опредёнными патчами, то по этому пути она увидит другую версию libastral, не ломая при этом работу других приложений.

Таким образом можно предоставлять любые ресурсы: библиотеки, конфиги, логи, исполняемые файлы, что угодно. Именноп о тем путям, которые хочет видеть программа. Проблема с прибитыми на гвозди библиотеками и исполняемыми файлами — самая острая, но это лишь частный случай более общей проблемы: потребности динамически формировать окружение, в котором работает программа. Вот это вещь, которую реально стоило бы улучшить в Юникс, а не заниматься перерисовыванием иконок, переписыванием гномов и правкой загрузочных скриптов в *надцатый раз подряд, чем щас занимаются всякие бессмысленные проекты типа freedesktop и пилильщики очередного дистрибутива.

Вариантов реализации можно придумать много, самый простой «в лоб»: формирование отдельного корня с нужными линками и chroot в него при выполнении exec. Пространство имён для такого виртуального корня может формироваться на основе общесистемных настроек, настроек пользователя, настроек пакета, к которому принадлежит запускаемый бинарник и т.п.

>Про KISS тоже забывать не стоит

Ничто не мешает либо вовсе не использовать предложенный механизм и работать по-старому, либо один раз статически сформировать пространство имён из заданной конфигурации и использовать только его.

>Сложность тестирования например.

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

я так понял что ЛуньОС пытаются заточить под это же

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

Собственно, что мешает написать обёртку для запуска

Да ничего не мешает, кроме отсутствия среди широких масс разработчиков осознания необходимости отвязаться от жестких реальных путей в ФС при запуске программ. Костыльный скрипт для личного пользования — не вопрос, но в одиночку «писать на коленке свой APT» вот именно что не хочется.

appshell - велосипед, есть AppImageKit (http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf), а иерархия ФС - просто hard линки с /etc в /System/Settings, с /home в /Users, c /usr/lib в /System/Libraries, и т.д. В GoboLinux все было намного интересней...

Выглядит как г..но.

попахивает макобунтой... закопать, да? =)

Как-то второй скриншот уж очень маковенько выглядит