LINUX.ORG.RU

Система Gentoo с KDE 4.7.0. на нетбуке asus n10j


0

1

Цель преследовалась сделать работу с приложениями удобной при разрешении 1024x600 и без большой нагрузки на зрение с минимальными затратами времени на доработку. Приняты во внимание мнения по оформлению и минимизации захламления рабочего пространства. Что-то использовано, что-то из вариантов показалось пока непривычным.

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

Тема оформления Androbit. Наиболее удачным показалось оформление окон как ни странно стандартное oxygen, совсем немного настроенное вручную. Причем oxygen работает достаточно быстро, если пакет qt-gui собран с флагом raster. Установлен удобный анимированный курсор Eclipse и значки из пакета JEY!style Remix. Цвета подбирал частично сам, но на основе наиболее подходящей по оформлению темы halloween. Шрифты Nimbus Roman No9 L, в консоли шрифт Andale Mono. Gtk приложения пока частично приближены к qt хотя бы по цветовому балансу благодаря теме Raleigh (см. оформление gimp).

Панель немного осветленная, состоит из значка меню Gentoo, сиреневой папки для запуска dolphin от обычного пользователя, красной папки для запуска dolphin из-под root, датчиков загрузки процессора и сети, переключателя трех рабочих столов, отделяющего менеджер задач smooth task от датчиков, а также системного лотка и часов. Для более детальной информации о ключевых параметрах системы настроен conky. Дублирование менее информативных датчиков и часов на панели обусловлено тем, что эта полупрозрачная панель перекрывает любые окна и постоянно на виду. Меню и диалоги выводятся с использованием небольшой полупрозрачности. Вывод всех рабочих столов осуществляется по перемещению курсора в левый верхний угол, вывод всех приложений по перемещению курсора в правый нижний угол. Смена прозрачности окон с помощью прокрутки в заголовке окна.

Консоль KDE запускается в виде выпадающего по F12 терминала yakuake.

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

Есть предложения, что еще можно было бы доработать или переделать?

Заранее благодарен.

>>> Просмотр (2066x2454, 1356 Kb)

★★

Проверено: JB ()

gimp ужасно смотрится с перекрашеной «дефолтной» гтк-темой..

jeuta ★★★★ ()

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

лови плюсик :)

tazhate ★★★★★ ()
Ответ на: комментарий от megabaks

На вкус и цвет товарищей нет. Мне нравится oxygen. А ещё мне нравится oxygen-transparent, только он жутко лагает на нетбуке (размытие на интелевой видяхе — это печально), поэтому юзаю классический oxygen.

gentoo_root ★★★★★ ()
Ответ на: комментарий от gentoo_root

вот именно - на вкус и цвет
а курва может быть любой, в отличии от

megabaks ★★★★ ()
Ответ на: комментарий от Lennox

С моей точки зрения #c3b3a6 - близко к сиреневому цвету. Проверял на двух компьютерах с соответствующими icc, в т.ч. и на своем специально загрузил винду со своим профилем icc дабы сравнить с линуксовым профилем.

Вот задачка для всех желающих сравнить соответствие цветовой гаммы:

http://clip2net.com/clip/m23976/1315930401-cliptj2436-28kb.png

Лучше всего открыть это изображение или в photoshop или в gimp с настроенным цветовым профилем.

glibych ★★ ()
Ответ на: комментарий от luke

Use the QtCurve or oxygen-gtk, glibych!

Thanks. And what's better?;)

P.S. Намекнули уже на oxygen-gtk. Внедрил, скрин выложил выше. Установить QtCurve тоже попробую позднее, сравним результат.

glibych ★★ ()
Ответ на: комментарий от ymuv

Компилил на нетбуке только? Сколько времени ушло на компиляцию?

Atom процессор сам по себе достаточно унылый камень, если не считать более менее приличного энергосбережения. Первый раз на полную компиляцию ушло немногим более 3,5 суток. Список пакетов достаточно внушительный включал и libreoffice и kde и прочие тяжелые пакеты. Причем это учитывая, что вначале было оптимизировано ядро (~25 минут), gcc (~45 минут) и основные системные библиотеки, а потом уже все прочие пакеты. Теперь обновления происходят быстро. В принципе во время компиляции нормально работалось с документами - сильных тормозов не наблюдалось.

glibych ★★ ()
Ответ на: комментарий от teddybear

Эти засечки можно заменить на ...*оделся в пакетик от помидор*... tahoma. (Ну, или поиграться с PT-Sans(Например, в варианте Narrow)|DroidSans|Ubuntu-fonts)

Еще раз посмотрел все шрифты, что есть в наличии у меня сейчас на системе. Без засечек наиболее удобоваримым оказывается arial, мне кажется он выглядит даже интереснее droid. Но все равно смотрится как-то не по людски. Остается вариант либо скопировать проприетарщину, либо ваять самому.

glibych ★★ ()
Ответ на: комментарий от megabaks

куча прозрачности

ШГ с засечками убогая якуака сливная ручка ниачём

Хотелось бы, чтобы Вы раскрыли тему. Почему сливная? И почему ни-а-чем? Для меня польза есть! Я слушаю Ваши советы, наматываю на ус и корректирую в лучшую сторону. Если 100 раз уже сказано, что шрифт плох и один подтвердил, что не совсем уж и Г. То в любом случае нужно будет поработать в этом направлении.

На Вашем сайте megabaks предлагаю скорректировать строчку в разделе оптимизации kernel:

«для Celeron-ов и Atom-ов можно оставить -Os т.к. у них маленький кэш»

Неверное направление для оптимизации. С использованием компилятора gcc 4.4.5 (на текущий момент лучший для данного процессора, хоть и не поддерживает флаг оптимизации atom), например, для atom n270 найдена вполне приличная комбинация для включения в Makefile, а вариант Os рвет даже стандартный вариант O2. Как правильно подкорректировать напишу чуть позднее.

Пока можно порешать еще задачку:

Почему, к примеру, с Timer frequency=1000Hz ядро загружается быстрее, чем с Timer frequency=100Hz даже на atom n270, хотя по производительности 1000Hz однозначно медленнее? Разница в скорости загрузки может быть более, чем в 2 раза;)

glibych ★★ ()
Ответ на: комментарий от glibych

oxygen-gtk красивее на мой взгляд. Хотя и курву иногда можно допилить.

luke ★★★★★ ()
Ответ на: комментарий от gentoo_root

зачем 8 gb swap при 2 gb ram

Например, собирать libreoffice в tmpfs.

Плюсую. Логично ведь, правда? Libreoffice версии 3.3.2 и выше до 7.9 Gb откушивает в таком режиме компиляции. А tmpfs экономит время компиляции больших пакетов.

glibych ★★ ()
Ответ на: комментарий от gentoo_root

И что, собственно, нестандартного? 2 свопа, что ли? Зачем?

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

Но первоначальны вопрос был такой:

Кстати, зачем 8 gb swap при 2 gb ram

Мой ответ: «Операции со файлом подкачки быстрее, чем обычные операции с файлами. У меня нестандартный fstab.»

Ваш ответ: «Например, собирать libreoffice в tmpfs.»

Суть одна в принципе. Ваш ответ более конкретный.

glibych ★★ ()
Ответ на: комментарий от glibych

потому что гтк и кутэ софт будет максимально идентичен с виду

megabaks ★★★★ ()
Ответ на: комментарий от glibych

про таймеры - бОльший отклик
а производительность при загрузке ядра разве что на распаковке нужна, которая занимает доли сек
а вот про атом и -O2/-Os не распарсил:
то неверное направление
то внезапно рвёт - кто кого?
выразись яснее

megabaks ★★★★ ()
Ответ на: комментарий от megabaks

про таймеры - бОльший отклик

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

Верно. Причем не спасает и NO_HZ=y. Кстати тоже интересная заметка из практики - при NO_HZ=n обычно производительность тоже валится. И порою прилично. Хотя очень часто можно встретить советы не использовать NO_HZ.

а вот про атом и -O2/-Os не распарсил:

то неверное направление то внезапно рвёт - кто кого? выразись яснее

Да вроде все просто, правда ответ не лежит на поверхности. Флаг Os очень плохо сказывается на производительности atom n270. И тут кеши L1 и L2 играют уже меньшую роль, чем скорость процессора. Он к несчастью не имеет возможности внеочередного исполнения команд и несмотря на два «виртуальных» ядра производительность обоих совместно редко достигает приличного коэфициента. Стоит еще заметить, что некоторые операции ко всему прочему выполняются за гораздо большее количество тактов по сравнению даже с другими аналогичными не шустрыми процессорами. Если вспомню куда уложил отчеты, тогда смогу дать даже конкретные цифры. Проверено с разными ядрами и четвертыми версиями gcc. Поэтому даже стандартный флаг O2 при компиляции в Makefile позволяет работать ядру на atom n270 быстрее. Не знаю насколько яснее получилось, но детальнее точно.

glibych ★★ ()
Ответ на: комментарий от zld

Хорошо, что еще сумели дочитать в переписке все что здесь перечислили, а ведь могло и врасплох застать;)

Приведите сюда ссылку на снимок своего рабочего стола для приличия. Может научимся чему.

glibych ★★ ()
Ответ на: комментарий от x0r

>толсто

Чего толстого? Я тоже собираю libreoffice на нетбуке. Только его не в tmpfs, а в /home с помощью $PORTAGE_TMPDIR, потому что у меня нет столько свопа, а ещё там один линкёр несколько гигов при работе хавает.

gentoo_root ★★★★★ ()
Ответ на: комментарий от glibych

>до 7.9 Gb откушивает

Последний офис занимает при сборке 9 гигов + ещё нужна память для работы gcc и ld (тоже пару гигов в особо тяжёлых случаях).

А tmpfs экономит время компиляции больших пакетов.

Если бы было 8 гиг оперативы, то экономил бы. А так, в свопе всё равно идёт скорость винчестера, как и на обычной ФС. Та часть tmpfs, что находится в ОЗУ, работает с такой же скоростью, что работал бы дисковый кэш. Так что один хрен — что ФС на разделе, что tmpfs.

gentoo_root ★★★★★ ()
Ответ на: комментарий от Deleted

ты лучше make.conf выложи

Да не проблема мне их не солить ведь, но нужно учесть, что make.conf еще не сформирован так как я хотел бы и там много лишнего сейчас:

http://paste.pocoo.org/show/475429/

С этими параметрами у меня сейчас компилируются и работают без проблем все, установленные мною, пакеты в gentoo на atom n270, за исключением некоторых самостоятельно отменяющих часть этих опций. Яркий пример тому gcc. Кроме того небольшое количество флагов отменяется мною.

Для оптимизации ядра для atom n270 можно также сменить флаги компиляции на эти:

HOSTCFLAGS = -O3 -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -mssse3 -g0 -Wno-all

HOSTCXXFLAGS = -O3 -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -mssse3 -g0 -Wno-all

Реально почувствуете разницу.

P.S.

Вместо "-mmmx -msse -msse2 -msse3 -mssse3" можно писать просто "-mssse3", но я предпочитаю полный вариант. Также можно дополнить оба этих параметра следующими флагами "--param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=512", указывая специфику данного процессора, но производительности это не поднимает. Из интересных вопросов: некоторые программы увеличивают свою производительность при указывании кеша L2 не 512, а 256 метров, причем достаточно серьезно. Стоит заметить, что я не решил этот вопрос однозначно чему отдать предпочтение.

Надеюсь по опциям ядра сами сможете. Если нет, то могу и один из вариантов файла конфигурации подарить.

glibych ★★ ()
Ответ на: комментарий от firsttimeuser

А у Вас какие иконки и шрифты? Может и мне впору придутся? Заранее благодарен.

glibych ★★ ()
Ответ на: комментарий от gentoo_root

Да, вспомнил кажется почему в fstab увеличил значение до 9 гигов. Ошибся немного. Компилировал libreoffice 3.3.4, когда его размаскировали и у меня, если память не подводит, до 8.6 гигов тогда было задействовано. Но свопы я не увеличивал получается 8 гигов общего свопа + 2 гига оперативки хватило перемолоть его.

P.S. Одного не могу понять - почему(!) libreoffice не разобьют на маленькие приложения?! Мне лично за глаза хватает электронных таблиц и редактора документов, ну максимум может еще базу данных прихватил бы. Остальное я лично не использую. Перешел бы на gnumeric - так тот таблицы с автофильтром периодически либо вообще не открывает, либо при снятии/выборе фильтра вываливается (параметры компиляции для него что-ни на есть щадящие ставил).

glibych ★★ ()
Ответ на: комментарий от x0r

Удовольствие работы с более быстрой программой перевешивает 6-7 часов компиляции во время сна. Пока я отсыпаюсь он успевает его скомпилировать. А с ccache еще и попадаются части кода, которые не обновлялись и просто заново берутся из кеша.

glibych ★★ ()
Ответ на: комментарий от x0r

>есть бинарная сборка

Почему-то с ней он в KDE на нетбуке выглядел, как г-но (хотя на десктопе всё работает). Т.е. тему gtk он не подхватил. Я забил и решил просто собрать его с USE=«kde».

gentoo_root ★★★★★ ()
Ответ на: комментарий от glibych

>почему(!) libreoffice не разобьют на маленькие приложения?!

В бинарных дистрах его разбивают, ЕМНИП. Это ж в Генте всё целиком. Хотя Qt разбивают, но тоже нет деления на -dev-пакет и обычный.

gentoo_root ★★★★★ ()
Ответ на: комментарий от x0r

>graphite

Ох, представляю себе, сколько будет собираться офис с графитом. Когда-то собрал так Firefox, больше не рискнул так делать.

gentoo_root ★★★★★ ()
Ответ на: комментарий от x0r

>не осилил переменные окружения OOO_FORCE_DESKTOP

Эту осилил. Ставил и gnome, и kde, было одинаково.

SAL_USE_VCLPLUGIN

Эту таки не осилил, не знал о ней.

Почему-то openoffice-bin на соседнем компьютере с KDE отлично выглядит из коробки, а libreoffice-bin выглядит, как г-но, с любым $OOO_FORCE_DESKTOP. Может, она как-то по-другому называется?

gentoo_root ★★★★★ ()
Ответ на: комментарий от gentoo_root

Ну сейчас все хорошо на самом деле :) Не собрался только PyQt4, т.к. gcc сегфолтится. Пришлось cflags для него фильтровать. Все остальное GRAPHITE="-floop-interchange -floop-strip-mine -floop-block -fgraphite-identity" CFLAGS="-march=native -O2 -pipe -mmmx -mssse3 -mfpmath=sse ${GRAPHITE}"

x0r ★★★★★ ()

Мне нравится. Приятное цветовое решение.

le_legioner ★★ ()
Ответ на: комментарий от x0r

ну да, ну да, а смысл генты в -O3, graphite и все такое

Во, во, как раз про флаги такие как graphite говорят те кто в этом ничего не шарит. С ним не собираются нормально приложения, если и собираются, то выигрыш теряется на фоне потерь производительности одновременно работающих приложений. На домашних системах его использовать ну никакого смысла нет. Бесполезно пытаться размножать не размножаемое. Нет еще ни нормальных многоголовых домашних драконистых процессоров, ни кода способного переложить часть задач на тот же gpu без участия человека, а для приличных вычислителей напишут и вручную нужный кусок кода.

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

glibych ★★ ()
Ответ на: комментарий от glibych

> На домашних системах его использовать ну никакого смысла нет.

Начинаю жалеть, что игнорирую мегабакса.

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

казалось бы причем тут graphite?

а для приличных вычислителей напишут и вручную нужный кусок кода.

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

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

см. выше

x0r ★★★★★ ()
Ответ на: комментарий от x0r

казалось бы причем тут graphite?

Не стоит обижаться. Просто представьте, если включить флаг graphite для того же атома и попробовать с ним собрать все (будем считать что даже все соберется). Получается, что комп с atom как минимум на недели 2-3 уйдет в глубокое самокопание?

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

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

P.S.

Сравнил производительность oxygen+raster vs qtcurves. Qtcurves шустрее процентов на 35-40 примерно. Вот только сколько займет времени его доводка до одинакового состояния в приложениях qt и gtk?((

glibych ★★ ()

Традиционно ШГ

Зачем в меню шрифт с засечками?

А вообще нетбуки совсем обнаглели в последнее время-- последние кеды уже без тормозов взлетают. Блендеры всякие. Сколько времени на нем кеды эти самые собирались? Или бинари ставил?

gorgoroth ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.