Собрал пакеты под кубунту (либы и базу от 29,06) пишу привет из konqerora 3,91,0 система работает но несколько падучая, жить можно прусь от плазмойдоф ;)
У меня ещё дисковый кеш на уровне 400Мб и я когда-то давно брал себе ОЗУ не для того, чтобы хвастаться, что у меня 900Мб свободно, а чтобы мне было комфортно работать и винт не грелся. KDE-3.5.7 я запускал и на 64Мб ОЗУ - да, и занимало это ~50%, но из-за постоянного обращения к винту, загрузки-выгрузки библиотек нормально работать было невозможно.
>у меня гном со всеми перделками и апплетами занимает 100-120 метров
у меня вин_хр грузится за <14cек. и занимает в озу <100Мб и что?
> У меня ещё дисковый кеш на уровне 400Мб и я когда-то давно брал себе ОЗУ не для того, чтобы хвастаться, что у меня 900Мб свободно, а чтобы мне было комфортно работать и винт не грелся.
тебе обьяснить разницу между занятой памятью и памятью, отведенной под дисковый кеш? У меня на ноутбуке кеш занимает всю доступную ОЗУ, но при этом лишь 150-200 метров занято приложениями
hint: нужно смотреть на "-/+ buffers/cache" в выводе free
> у меня вин_хр грузится за <14cек. и занимает в озу <100Мб и что?
а ничего. Я вообще непонимаю нахрена ты приплел сюда венду :)
>Монолита в кедах нет и никогда не было. Кеды всегда были и будут модульными.
Ужоснах. В Linux, ИМХО, не более монолитных структур, чем KDE. При чём обязательно нужно всё затащить внутрь себя, сторонними пакетами пользоваться - не дай Бог! Вот и переносятся net-im/kopete в kde-base/kopete, x11-plugins/superkaramba в kde-base/superkaramba и т.д. и т.п. Ладно, хрен бы с ним, с kde*, но за каким хреном тот же PyQt мне сейчас приходится ставить не самостоятельный, а, опять же, из KDE! Ибо "сторонний" PyQt в KDE сегодня просто не работает. Всё, блин, надо к себе затащить...
Вообще, достаточно сравнить, например, количество внешних зависимостей того же Gnome и KDE, чтобы понять, кто из них использует Unixway, задействуя сторонние разработки, а кто - тащит всё внутрь себя, как винды.
Вот практический вопрос - у меня есть скрипты, типа mht2png или fb2cover2png. В Гноме я одной строчкой подключаю их в качестве генератора превьюшек для Наутилуса. И у меня .mht показывается как документ, и .fb2.zip рисует обложку книги. А вот как то же самое в KDE сделать? Только писать соответствующие расширения к конкуреру. Ибо расширяемость в KDE - никакая. Монолит.
> > Монолита в кедах нет и никогда не было. Кеды всегда были и будут модульными.
> Ужоснах. В Linux, ИМХО, не более монолитных структур, чем KDE. При чём обязательно нужно всё затащить внутрь себя, сторонними пакетами пользоваться - не дай Бог! Вот и переносятся net-im/kopete в kde-base/kopete, x11-plugins/superkaramba в kde-base/superkaramba и т.д. и т.п. Ладно, хрен бы с ним, с kde*, но за каким хреном тот же PyQt мне сейчас приходится ставить не самостоятельный, а, опять же, из KDE! Ибо "сторонний" PyQt в KDE сегодня просто не работает. Всё, блин, надо к себе затащить...
kopete и karamba - чисто kde-шные приложения, в чем вообще вопрос? Насчет PyQt не особо в курсе, но что значит "сторонний" и "из KDE"?
> Вот практический вопрос - у меня есть скрипты, типа mht2png или fb2cover2png. В Гноме я одной строчкой подключаю их в качестве генератора превьюшек для Наутилуса. И у меня .mht показывается как документ, и .fb2.zip рисует обложку книги. А вот как то же самое в KDE сделать?
А вот никак, ну вот не предусмотрели именно эту твою хотелку, и заморозили третьи кеды полтора года назад. Все, жизнь кончилась. Теперь в каждом топике будешь про эту фигню писать? Понятно ведь, что не все можно добавить средствами bash.
> Только писать соответствующие расширения к конкуреру. Ибо расширяемость в KDE - никакая. Монолит.
Расширяемость не обязана реализовываться через bash. Ты ведь не осуждаешь gimp или firefox за невозможность писать расширения на bash?
>А вот никак, ну вот не предусмотрели именно эту твою хотелку, и заморозили третьи кеды полтора года назад. Все, жизнь кончилась. Теперь в каждом топике будешь про эту фигню писать? Понятно ведь, что не все можно добавить средствами bash.
а почему в гноме можно? Это потому что гном кастрированый, хиганутый и всё такое? :)
>Расширяемость не обязана реализовываться через bash. Ты ведь не осуждаешь gimp или firefox за невозможность писать расширения на bash?
> для написания расширений к конкверору надо вооружаться плюсами и обкладываться томами мануалов
Для написания расширений к Gimp надо вооружаться C или Python и обкладываться томами мануалов. Gimp - аццкий монолит? Ядро linux - аццкий монолит, hurd - наше фсио?
>Для написания расширений к Gimp надо вооружаться C или Python и обкладываться томами мануалов. Gimp - аццкий монолит? Ядро linux - аццкий монолит, hurd - наше фсио?
питон к гимпу требует мануалов? Попробуй сравнить скорость и простоту разработки на питоне и на С++. Про отладку не забудь. А ядро - это вообще системное программирование. Хотя и тут fuse-python и торчащие наружу интерфейсы позволяют много сделать на любых ЯП.
>Потому, что разрабы гноме решили, что это - важная фича.
важная фича - это модульность. Начтоящая, а не "а вот эту библиотеку в пмять можно не грузить, если она не нужна". И расширяемость - тоже немаловажная вещь
>Что-то не видать подобных сообщений в этой ветке...
Названия функций и объектов и их смысл наизусть помнишь?
> Попробуй сравнить скорость и простоту разработки на питоне и на С++. Про отладку не забудь.
Посмотри с другой стороны, заходит юзер в каталог... и для каждого файла запускается по интерпретатору(создается отдельный процесс...) perl, python, ruby, php (ну нужен был просмотр какого-то формата кодеру на php). Вот это - Ъ, а то, что винт шуршит и памяти дофига отъедается - пох.
> А ядро - это вообще системное программирование. Хотя и тут fuse-python и торчащие наружу интерфейсы позволяют много сделать на любых ЯП.
Я про то, что практически всегда для того, чтобы существенно расширить функциональность проги требуется писать код и чесать репу. На каком языке - дело десятое.
>Названия функций и объектов и их смысл наизусть помнишь?
девелопинг в рантайме + dir() :)
>Посмотри с другой стороны, заходит юзер в каталог... и для каждого файла запускается по интерпретатору(создается отдельный процесс...)
доведем идею до абсурда и используем этот абсурд в качестве аргумента? Занкомый прием, незачет
>Я про то, что практически всегда для того, чтобы существенно расширить функциональность проги требуется писать код и чесать репу. На каком языке - дело десятое.
т.е. ты искренне уверен, что на плюсах писать так же легко и быстро, как и на баше/питоне/перле? :)
> > Потому, что разрабы гноме решили, что это - важная фича.
> важная фича - это модульность. Начтоящая, а не "а вот эту библиотеку в пмять можно не грузить, если она не нужна". И расширяемость - тоже немаловажная вещь
Модульность - это не обязательно крепежь всего и вся через bash/вызов процессов и т.д. ...
> доведем идею до абсурда и используем этот абсурд в качестве аргумента? Занкомый прием, незачет
А сейчас оно не так? Эту панель писал перец, знающий питон - грузим питон. Этот поисковик писали люди, знающие C# - грузим mono, этот апплет к панели..... Крон приводил Gnome в пример в том, что preview-шки генерятся отдельными приложениями, значит эти приложения вызываются когда я захожу в каталог. На чем они написаны, и сколько рантаймов за собой потянут - вопрос открытый.
> т.е. ты искренне уверен, что на плюсах писать так же легко и быстро, как и на баше/питоне/перле? :)
Нет, я к тому, что от чтения доки/изучения API тебя питон не спасет.