Объявлена дата релиза Mandriva 2010.2

План на данный момент чинить их по частям. С msec и net_monitor, проще было их с нуля написать (что собственно и было сделано для 2009.1 и 2010.0). Насчет остальных надо думать...

У меня есть встречное предложение.. Я конечно понимаю что на ЛОРе это немного безнадежно обсуждать, но есть что-то конкретное в MCC что не может быть сделано либо например через KDE systemsetting, либо автоматически? Не флейма ради, но у меня есть такое ощущение что через «network and connectivity», «system settings» и «system administration» можно все унифицировать например.

Тут вопрос в другом - в KDE ладно, сделаем. А в других DE? Мне кажется MCC надо переписать на том же Python, контекстно заменяя инструменты. Иначе это уже будет не Мандрива.

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

Ты сам-то хоть исходники читал? Код там очень читабельный и понятный. Единственное - синтаксическая мешанина.

>А в других DE?

Да, LXDE + MCC - это гораздо серьезнее, чем просто LXDE :)

Мне кажется MCC надо переписать на том же Python, контекстно заменяя инструменты.

А разве можно вызывать модули на перле из питона и наоборот? Иначе ни о какой постепенной миграции речи нет

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

Мне кажется MCC надо переписать на том же Python, контекстно заменяя инструменты.

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

иначе много лопатить, для каждого de делать интеграцию, это будет сложно и не гибко, а что делать тем кто не пользуется de вообще?

>Ты сам-то хоть исходники читал? Код там очень читабельный и понятный. Единственное - синтаксическая мешанина.

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

>+ и очень даже жирный +

...лишь бы перл не учить)

...лишь бы перл не учить)

=) эм, возможно буду, но не уверен. По теме: если переписывать, то 2 пути, перекопать тот же перловый код и сделать его нормальным, второй что-то еще(как и сказали выше питон). На перле не писал, а вот питон очень прост, и лопатить не долго придется. Правда если все делать по человечески, и чтобы в будущих релизах меньше багов было, то лучше путь 1.

путь 1 явно лучше, так как даже если в конечном счете придется все периписывать, представлять, как все устроено, все равно нужно. Иначе эти 10 лет разработки вылетят в трубу

путь 1 явно лучше, так как даже если в конечном счете придется все периписывать, представлять, как все устроено, все равно нужно. Иначе эти 10 лет разработки вылетят в трубу

Как я и сказал- если «делать все по-человечески».

> Ты сам-то хоть исходники читал?

(В звездочку рядом с моим ником ткнуть недосуг?)

Я согласен, это было бы здорово!

Постепенно переписать возможно, например, mcc с system-config-printer, tomoyo-gui и msec-gui работают. Но это частные случаи, большинство других drakxtools они дергают куски кода на перле напрямую. И как это все оттранслировать я собственно говоря себе не представляю.

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

К сожалению, если бы знал бы как это делать в перл, то сказал бы, но увы. Можно поставить это в список на вики. С питоном вопрос, достаточно ли персонала у компании, способного так много переписать на питон, так что бы код хотя бы работал?

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

Я в основном интересуюсь как пользователь, ведь намерен еще долго оставаться на мандриве.(4 год пользуюсь линуксом и только и уже как 2ой год мандривой.)

С точки зрения быстродействия я бы сказал как perl так и python в большинстве случаев одинаковы. Все зависит от кода.

Насчет ресурсов - так я про это и говорю, в этом и состоит часть дилеммы. Вместо того, чтобы переписывать один-в-один все с перла на питон, не лучше ли было бы эти усилия в другое русло направить, на развитие собственно говоря десктопа в целом? :)

>Ты сам-то хоть исходники читал? Код там очень читабельный и понятный. Единственное - синтаксическая мешанина.

О-о-чень понятный. Только вот программеров на perl днем с огнем не сыщешь. И обычному программеру в нем разбираться, тоже самое что технарю философский трактат разбирать по филологическим принципам. Хватит с меня несколько убитых дней для добавления DNS NetPolice в drakguard и вызова приложения из модуля vpn в MCC :(

Вопрос стоит более философски - нужен ли MCC в том виде, в котором он есть. Так как к примеру настройка раскладки клавиатуры уже с 2010.0 дает сбой (баг с winkeys) и т.п.

Да, LXDE + MCC - это гораздо серьезнее, чем просто LXDE :)

главное чтобы настройки были в одном месте, а не в двух и более как сейчас.

> Вместо того, чтобы переписывать один-в-один все с перла на питон, не лучше ли было бы эти усилия в другое русло направить, на развитие собственно говоря десктопа в целом? :)

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

на развитие собственно говоря десктопа в целом? :)

без mcc не будет смысла что-то развивать, нужен скелет, и в моем представлении это mcc(переписанный или новый)+urpmi. А уж потом de и все к нему.

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

хорошая идея

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

?

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

Собственно и я об этом :(.

Вопрос стоит более философски - нужен ли MCC в том виде, в котором он есть.

Собственно да... MCC обогнал свое время, но на данный момент я думаю что этот филосовский вопрос очень даже актуален. Зачем нужны два центра настройки если все можно сделать в одном?

Я вижу два выхода: либо его (MCC) переосмыслить, либо сделать так, чтобы необходимость в нем отпала.

С нашей точки зрения, второй пункт более интересен и выполним.

тогда нам, сообществу, придется интегрировать нужные инструменты в утилиты настройки поддерживаемых DE.

является ли это простым и рациональным решением с вашей точки зрения? если в lxde еще как-то просто что-то впихнуть, что же с другими de, и что делать пользователям wm+panel

что останется «фишкой» мандривы? =(

> С нашей точки зрения, второй пункт более интересен и выполним.

Тогда это надо обсудить будет со всеми «ответственными» за коммунити DE - GNOME, XFCE, LXDE и т.п. Какие инструменты оставить и как это все будет вызываться и т.п. Так как инструменты в разных DE будут не совпадать. К примеру в LXDE можно объединить наработки LXAdmin, инструментов lx... и вызовом функций drak. Но этот центр управления должен совпадать (вплоть до внешнего вида) с таким же в KDE или Gnome, иначе опять разнобой. Как тогда обеспечить визуальное и юзабильное единство версий на разных DE?

> если в lxde еще как-то просто что-то впихнуть

Не просто. Существующие реализации центров и ПО (по типу lxadmin) построены или на инструментах и особенностях Debian/Arch (то есть расходятся с Мандривой). По другим DE не скажу, но пилить тоже придется.

Зачем нужны два центра настройки если все можно сделать в одном? Я вижу два выхода: либо его (MCC) переосмыслить, либо сделать так, чтобы необходимость в нем отпала.

Тогда есть гораздо более простое решение:

• Берем Федору
• Прокачиваем в ней KDE, добавляем в systemsettings инструментарий из MCC
• Добавляем недостающие пакеты (или просто пересобираем кукер в новой среде)
• Добавляем кошерные rpmmacros (если в Федоре не лучше:)
• ???
• PROFIT!

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

>является ли это простым и рациональным решением с вашей точки зрения? если в lxde еще как-то просто что-то впихнуть, что же с другими de, и что делать пользователям wm+panel

насколько я понимаю, официальная позиция такая: 1) не использовать другие де или 2) писать велосипед для своего любимого окружения

Насколько мне известно, существует еще несколько дистрибутивов, использующих MCC (PC Linux OS - не единственный). Если вынести сорсы MCC в отдельный SVN (или Git), и попробовать начать документировать код, может быть, удастся достичь какого-то объединения усилий?

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

>>глюки с отображением в 4х кедах

что это?

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

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

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

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

ну вот это из той же оперыю Хотя у меня на домашнем после обновления это не появилось

А кто её сейчас делает? Все ключевые разработчики сто лет как пилят mageia. Кукер тоже уже давно не обновлялся — там до сих пор висит древняя бета kde 4.4.

>Все ключевые разработчики сто лет как пилят mageia.

4.2 же, эта поделка никому не нужна, кроме маленькой кучки энтузиастов

Кукер тоже уже давно не обновлялся — там до сих пор висит древняя бета kde 4.4.

там 4.5.80 вообще-то, наверно это ты давно не обновлялся :)

и на стэбл обновления каждый день приходят

там 4.5.80 вообще-то, наверно это ты давно не обновлялся :)

Да, перепутал, это на самом деле 4.6 бета. А 4.5 вообще не было и видимо не будет.

Я сижу на кукере и боюсь его обновлять с тех пор как там появилась бета KDE, а релиза всё нет и нет. А назад на 2010.1 уже слишком геморройно будет откатываться.

>Я сижу на кукере

а я сижу на 2010.1 и не боюсь :) Правда апдейт нвидевского блоба прошел неудачно, пока сижу на nv

Это типа шутка такая?

[eugeni@eugeni-x86_64 22:13:01 ~] $ rpm -q kdebase4-workspace kdebase4-workspace-4.5.80-1mdv2011.0 [eugeni@eugeni-x86_64 22:13:54 ~] $ cat /etc/mandriva-release Mandriva Linux release 2011.0 (Cooker) for x86_64

Наачет ключевых разработчиков в Mageia - это тоже немножко спорно...

Наачет ключевых разработчиков в Mageia - это тоже немножко спорно...

Оттуда ушли все разработчики, которые делали всю инфраструктуру. Посмотри список. А инфраструктура там на жесточайшем перле, кто это теперь будет поднимать мне не совсем понятно.

Все ключевые разработчики сто лет как пилят mageia.

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