LINUX.ORG.RU

Начинающий гентушник выбирает рабочий стол

 , ,


1

1

Не так давно обновил Ubuntu до 12.04 и все завер...
В двух словах: убунта теперь не удовлетворяет моему основному требованию «работать без дополнительных настроек из коробки». А т.к. теперь систему все равно придется настраивать самому, решил остановить свой выбор на Gentoo, чтобы уже совсем не зависеть от сборщиков дистрибутива.

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

Немного о моих требованиях:
* все это безобразие должно помещаться в минимальный объем памяти
* оно должно уметь рисовать окна и запускать программы
* настраиваемый внешний вид

До сих пор ностальгирую по GNOME2, но ставить его нет никакого желания, т.к. это путь в склеп.

Сейчас подумываю о IceWM или Xfce.

В ответах ожидаю увидеть советы по выбору этого безобразия и ссылки на полезные статьи.

P.S. Для начала можно помочь мне разобраться в отличиях между средами рабочего стола, менеджерами окон и т.п.

★★★★★

Последнее исправление: trex6 (всего исправлений: 1)
Ответ на: комментарий от fragment

Солнце, отвали.

Эт к маме

Ты своими смешными попытками выглядеть умником совсем не впечатляешь.

Хватит проецировать свое поведение на окружающий мир.

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

Стэдж4 свой еще собрать и настроить надо. А чужой ненужен же.

Ну так =) один раз надо

Nensha
()
Ответ на: комментарий от trex6

OpenBox + tint2. Подходит под требования идеально. Настраивается гибко и просто, все настройки хорошо описаны (правда на английском) в официальной wiki.

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

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

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

И s/виви/вики/i
Ох уж эти глянцевые мониторы нетбуков.

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

Зачем оверлей, если

avalon test # ls /portage/gnome-base/gnome-desktop/
ChangeLog                    gnome-desktop-2.32.1.ebuild     gnome-desktop-3.4.1.ebuild  metadata.xml
files                        gnome-desktop-2.32.1-r1.ebuild  gnome-desktop-3.4.2.ebuild
gnome-desktop-2.30.2.ebuild  gnome-desktop-3.2.1.ebuild      Manifest
avalon test # ls /portage/gnome-base/gnome-common/
ChangeLog                   gnome-common-2.34.0.ebuild  Manifest
gnome-common-2.28.0.ebuild  gnome-common-3.1.0.ebuild   metadata.xml
avalon test # ls /portage/gnome-base/gnome/
ChangeLog  gnome-2.32.1-r2.ebuild  gnome-3.2.1.ebuild  Manifest  metadata.xml

?

fragment
()
Ответ на: комментарий от Verkhovtsev_M_D

а оно «живое» разве?

Не развивается, но вполне себе живо.

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

по дефолту - да. Но гентушники суровы, владеют уличной магией расклеивания и гвоздодера :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от fragment
emerge -C то_что_ставил_руками
emerge --depclean

Ну и revdep-rebuild по вкусу. Где тут проблема, я честно говоря не понял. А если еще включать мозг и читать сообщения пакетного менеджера, то вообще проблем нету(за исключением кривых рук и неконсистного состояния системы, вызванного ими). Единственная проблема генты - попробуй беспроблемно обновиться после того как не обновлялся 5-6 месяцев. Вот это может занять некоторое время на копание в системе

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

emerge --depclean

Я уже говорил выше, что этот depclean вместе с действительно ненужными сносит и нужные пакеты. Типа nano.

fragment
()
Ответ на: комментарий от thelonelyisland
pinkbyte@phantom ~ $ eix akonadi -I
No matches found.
pinkbyte@phantom ~ $ eix nepomuk -I
No matches found.
pinkbyte@phantom ~ $ cat /var/lib/portage/world_sets 
@kdebase
[pinkbyte@phantom ~ $ cat /etc/make.conf | grep -i semantic
-handbook -oss -perl -python -semantic-desktop -v4l

Что Аконади? :-)

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

обновление glibc — и кирдык! Компиляй мир заново.

Facepalm.jpg. emerge -e world при обновлении glibc - дааавным-давно уже как необязательно. Года так 4-5.

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

сеты в помощь. У меня emerge -C @kdebase сносит пытается снести к чертям все пакеты в сете.

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

да. Если не ставить юз-флаги на зависимости, которые тебе не нужны. Скажем нет такого дебилизма, как в CentOS 5, когда mrtg на сервере тянет libpng(это нормально), которая тянет половину иксов(а это уже трындец!)

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

emerge -C @set и нет проблем. Все большие наборы пакетов давным-давно обзавелись сетами. Сеты для KDE находятся в соответствующем оверлее.

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

glibc имеет это в зависимостях
java

вот те раз! o_O

Это где так? я ТАКОГО говна ни в одном дистре не встречал

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

его, как и GTK+-2.x вроде ещё не собираются выкидывать из репозитория.

у меня для тебя плохие новости из уст одного из разработчиков Gentoo. Если некая программа X умеет и GTK2 и GTK3, то в генте будет отданно предпочтнение ЖЕСТКОЙ зависимости от GTK3(обратное возможно только, если интерфейс на GTK3 - кривое и падучее говно). Пруфы можешь загуглить на багзилле. Причина - недостаток разработчиков Gentoo GTK Team, поэтому они не могут поддерживать в стабильном состоянии 2 ипостаси интерфейсов для пакетов

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

упорно сносит nano

ох, как же достали меня эти фразы! Идем в /usr/portage/virtual/editor/editor-0.ebuild, смотрим строчку RDEPEND. Например, если у тебя стоит nano и mc с USE-flag edit, то предпочтение при удалении будет отдано mc, потому что в системе должен быть МИНИМУМ 1 редактор. Если так нужно nano:

emerge --noreplace nano

однажды он мне boost снёс

если пакет boost никем не требовался или присутствовал в 2 слотах - см. пункт 1.

В очередной раз повторяю: неумение пользоваться системой != недостаток системы

Pinkbyte ★★★★★
()

убунта теперь не удовлетворяет моему основному требованию «работать без дополнительных настроек из коробки». А т.к. теперь систему все равно придется настраивать самому, решил остановить свой выбор на Gentoo

из крайности в крайность)

P.S. Ставь fluxbox. Это так же как openbox, только будешь тянуть меньше пакетов, не придётся искать еще панельку, трей. Править конфиги будет легко и просто (а не xml, как в openbox'e). Плюс, в fluxbox'e можно создавать тэги и группировать в нём окна. Плюс «почти недотайлинг» для ленивых по хоткеям.

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

по какой-то причине убрали из системных пакетов

убрали для того, чтобы его можно было безболезненно грохнуть и заменить на vim, допустим, не используя package.provided

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

Где ты в генту «искоропки» видел?

stage4+prebuilt binary packages(не путать с протухшим GRP). ВНЕЗАПНО, Gentoo - это метадистрибутив, как хочешь так и крути.

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

а, ну если вам претит использование чужих стейджей то кагбе да - только вдоль :-)

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

Недостаток системы - это когда у ПМ нет штатного средства для удаления группы логически связанных пакетов типа kdebase-meta. Depclean, предназначенный для совершенно других целей и работающий врастопырку, а также подключение оверлеев к таким средствам не относятся. Понятно, что есть сеты, но почему их нет в стандартном дереве?

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

А для сборки он нужен, вот беда.

если он нужен для сборки какому-то пакету из портажа, а тот его не тянет - не ной здесь, пости баг на багзиллу. А если он нужен какому-то пакету НЕ ИЗ ПОРТАЖА - опять же не ной и выполни:

emerge --noreplace boost
Pinkbyte ★★★★★
()
Ответ на: комментарий от fragment

portage ничего сам не решает. Он поддерживает базу пакетов в консистентном состоянии на основе пожеланий пользователя. То, что ты не знаешь о принципах работы world-файла еще не значит, что этих принципов нет. Как я уже сказал - emerge --noreplace в помощь

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

Почему сетов нет в стандартном дереве? В стабильную ветку в генте принято коммитить только протестированный и отлаженный код. Функциональность сетов недостаточна протестирована - слишком мало отзывов от пользователей, слишком мало разработчиков в Portage Team.

Вывод: нужна расширенная функциональность не в ущерб стабильности - юзай ВЫБОРОЧНО пакеты из ~arch. Нужно всё новое - юзай ACCEPT_KEYWORDS=~arch.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от fragment

ну почему-то я таких вопросов как ты не задаю, имея ~20 серверов и парочку рабочих станций на генте? На всех юзаю --depclean и nano и УМВР. Может я сделал что-то нестандартное? Может я осилил прочитать man emerge? :-)

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от fragment

Depclean работающий врастопырку

незакрытые баги на багзилле, подтверждающие поведение «врастопырку»? Или 4.2

группы логически связанных пакетов типа kdebase-meta

метапакеты(как и виртуальные пакеты) не обеспечивают логической связанности для пользователя, они предназначены для упрощения зависимостей в самом пакетном менеджере. Логическую связанность обеспечивают сеты.

подключение оверлеев

базовый функционал, оттестированный и работающий СТАБИЛЬНО присутствует в главном дереве портажей. Нужно чтобы в главном дереве было что-то большее? Где твои реквесты на багзилле?

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

незакрытые баги на багзилле, подтверждающие поведение «врастопырку»?

Под растопыркой имелся в виду снос невинных пакетов.

метапакеты(как и виртуальные пакеты) не обеспечивают логической связанности для пользователя, они предназначены для упрощения зависимостей в самом пакетном менеджере

Конечно, это было так трудно сделать - парсинг списка зависимостей метапакета и их удаление. Куда легче навернуть ещё одну сущность в виде сетов.

базовый функционал, оттестированный и работающий СТАБИЛЬНО присутствует в главном дереве портажей

Во всех остальных ПМ удаление пакета с его зависимостями - базовый функционал. Но только не в portage, да.

А вот ещё крутотень: делаю я emerge -C $PACKAGE и у меня внезапно перестаёт работать какая-нибудь программа. Потому что $PACKAGE был у неё в зависимостях. А portage при удалении ограничился туманным намёком, что $PACKAGE может быть чьей-то зависимостью, да. А чтобы удостовериться, что $PACKAGE является зависимостью какого-то другого пакета, нужно выполнить другую команду equery <что-то там>. Это типа тоже круто и так и должно быть?

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

это было так трудно сделать - парсинг списка зависимостей метапакета и их удаление.
о всех остальных ПМ удаление пакета с его зависимостями - базовый функционал. Но только не в portage, да.

и сломать системы всем пользователям в случае ошибки алгоритма, ага. Необходимо сначала протестировать такое решение. Вдобавок сущности хоть и похоже, но кардинально отличаются направленностью. Сеты более правильны для пользователя, ИМХО. Ты не понимаешь, в source-based дистрибутиве с зависимостями все гораздо гибче(и сложнее) чем в binary-based. Почитай хотя бы про automagic dependencies(это не относится непосредственно к теме беседы, но дает забавную пищу для размышлений).

....Это типа тоже круто и так и должно быть?

Да. Потому что сделав «emerge -C библиотека»(пусть пакет который ты удалил будет библиотекой, для простоты размышлений) ты привел дерево пакетов в неконсистентное состояние. Это как с системами контроля версий - ты внес изменения, но не зафиксировал(commit) их. На самом деле - полезно для некоторых экспериментов. Для приведения дерева в консистентное состояние у тебя есть несколько вариантов:

1) revdep-rebuild

2) emerge @preserved-rebuild (Требуется portage 2.2)

Область применения п. 2 немного другая, возможно при этом будут лишние действия, но учитывая что требуешь ты(ОБЯЗАТЕЛЬНОЕ удаления пакетов, которые зависят от удаленного вручную) - это тебя не должно смутить.

Пример того момента, где такое поведение будет оправдано: предположим есть куча пакетов, зависящих от virtual/editor(взял для примера). Удаление, допустим, единственного редактора в системе(nano), по твоей логике должно вызвать автоматическое удаление этих пакетов(пусть их будет 200, скажем). А я ПРОСТО хочу заменить редактор по умолчанию, сначала удалив старый(nano), затем поставив другой(ну, может мне vi или emacs больше нравится).

Поведения в твоем случае приведет к тому, что 200 пакетов надо будет переустановить заново(введя их имена вручную или отследив их через emerge.log). Portage ИМХО поступает правильно, давая свободу пользователю в любых действих с пакетами. Можно удалить nano и засунуть его в package.provided. Можно удалить nano, поставить vi и зависимость от virtual/editor переключится на него сама.

И да, если тебе не нравится portage, в генте с недавних времен можно использовать альтернативные пакетные менеджеры - pkgcore и paludis. Я их не щупал, ибо меня всё устраивает

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

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

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

Ты не понимаешь, в source-based дистрибутиве с зависимостями все гораздо гибче(и сложнее) чем в binary-based

Ок, пусть после установки kdebase-meta я поставил несколько пакетов, использующих зависимости пакета kdebase-meta. Допустим, я удаляю kdebase-meta, вместе с ним удаляются зависимости и эти установленные пакеты ломаются. Ну и что же? Стандартная ситуация, которая исправляется командой emerge @preserved-rebuild. В чём проблема-то?

Да. Потому что сделав «emerge -C библиотека»(пусть пакет который ты удалил будет библиотекой, для простоты размышлений) ты привел дерево пакетов в неконсистентное состояние. Это как с системами контроля версий - ты внес изменения, но не зафиксировал(commit) их. На самом деле - полезно для некоторых экспериментов. Для приведения дерева в консистентное состояние у тебя есть несколько вариантов:

Это хорошо, когда отсутствие важного пакета идентифицируется сразу и очевидно. Например, программа валится, не найдя библиотеки. А если программа работает, но не так, как нужно? Допустим, не найдя удалённую либу, она стала использовать другую, но глючную?

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

Пример того момента, где такое поведение будет оправдано: предположим есть куча пакетов, зависящих от virtual/editor(взял для примера)

Пример не совсем корректный, потому что виртуальный пакет - совсем не то же самое, что метапакет.

И да, если тебе не нравится portage, в генте с недавних времен можно использовать альтернативные пакетные менеджеры - pkgcore и paludis

Мне нравится portage, поэтому я его и критикую. Если б не нравился, я бы молча сменил его на что-то другое. Paludis я щупал - тормозная глючная хрень.

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

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

Напиши реквест разработчикам. Видимо остальных такое поведение устраивает. И учти, что в данном случае возрастет время удаления пакета, т.к. придется просчитывать зависимости. Я думаю было бы неплохо иметь ключ, допустим -v для ключа -C, который реализует подобное поведение.

Однако учитывая загруженность Portage Team, думаю подобные реквест положат в долгий ящик :-(

Допустим, не найдя удалённую либу, она стала использовать другую, но глючную?

А за такое апстриму надо яйца отрывать. Зависимости от библиотек должны ставиться при сборке намертво(речь идет о приложениях на C/С++, Python и прочие интерпретируемые языки не в счет). Любые попытки программы «определять окружение» после сборки должны фикситься патчами

Pinkbyte ★★★★★
()

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

Почему не слака?

* все это безобразие должно помещаться в минимальный объем памяти
* оно должно уметь рисовать окна и запускать программы
* настраиваемый внешний вид

Xfce

До сих пор ностальгирую по GNOME2, но ставить его нет никакого желания, т.к. это путь в склеп.

mate

Сейчас подумываю о IceWM или Xfce.

про первое - не слышал второе советую ( хотя сам использовать не стал)

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

граф. среда это совокупность программ, предоставляющих графическое оформление (т.е например, файловый менеджер, рабочий стол, граф. панель настроек и т.д.), оконный менеджер - это программа, отвечающая за работу окон, уведомлений и тд
Про генту: философии генты не понял, честно. Установка не так сложна, что бы ей восхищаться, наличие бинарных пакетов (пусть и не многих ) позволяет обойти сложную компиляцию, а сложного в компилировании пакетов, с малым кол-вом зависимостей ничего нет. После настройки всяких X-в становится обычным, не интересным дистрибутивом.

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

Нет, потому что не был уверен, из-за чего это вообще, да и некогда, у меня глюки повеселее тогда были: http://forums.gentoo.org/viewtopic-t-920108.html Сейчас всё вроде окей, вот попробовал удалить ненужное (emerge -avc), а он мне вывел в списке libass. И хотя её правда нигде в USE флагах нет я подумал, что она нужна как минимум для mplayer, и на всякий случай проверил

# equery d libass
 * These packages depend on libass:
media-video/ffmpeg-0.10.3 (libass ? media-libs/libass)
media-video/mplayer-1.1-r1 (libass ? >=media-libs/libass-0.9.10[enca?])
Странно, но ни у mplayer, ни у ffmpeg флага libass нет. Должно быть, забыл добавить, так что указал мплееру флаг enca, и это по идее должно было поставить libass к нему в зависимости, так? Выполнил emerge -avc. Он снова вывел там libass и удалил. А теперь внимание — после запуска revdep-rebuild портаж решил, что мне надо пересобрать ffmpeg(!), которому по идее libass не нужна и он её никак не касается (флага-то нет)
…
[ 17% ]  *   broken /usr/bin/mencoder (requires libass.so.4)
[ 18% ]  *   broken /usr/bin/mplayer (requires libass.so.4)
[ 49% ]  *   broken /usr/lib64/evince/3/backends/libpsdocument.so (requires libspectre.so.1)
[ 67% ]  *   broken /usr/lib64/libavfilter.so.2.61.100 (requires libass.so.4)
[ 100% ]                 
 * Generated new 3_broken.rr
 * Assigning files to packages
 *   /usr/bin/mencoder -> media-video/mplayer
 *   /usr/bin/mplayer -> media-video/mplayer
 *   /usr/lib64/evince/3/backends/libpsdocument.so -> app-text/evince
 *   /usr/lib64/libavfilter.so.2.61.100 -> media-video/ffmpeg
 * Generated new 4_raw.rr and 4_owners.rr
 …
 * All prepared. Starting rebuild
emerge --complete-graph=y --oneshot   app-text/evince:0 media-video/ffmpeg:0 media-video/mplayer:0
…
>>> Emerging (1 of 5) media-video/ffmpeg-0.10.3
Вот так libass была вытянута ffmpeg, потому что оказалась нужна libavfilter, хотя во флагах её нет. Хотя, ffmpeg ведь стоит в зависимостях у mplayer, так что не совсем ясно, кому именно нужна поддержка libass в libavfilter. С другой стороны, mplayer, как и множество других плееров, имеет что-то своё для фильтрации постдекодированного аудио/видео, поэтому это вполне может быть и ffmpeg.

Deleted
()
Ответ на: комментарий от fragment
$ emerge --depclean --ask 

Перед сносом портаж 2 раза предупредит о том, что он собрался удалить с возможностью отказаться. Можно остановить и безболезненно решить проблему. Ведь будет выдано сообщение

 * Depclean may break link level dependencies. Thus, it is
 * recommended to use a tool such as `revdep-rebuild` (from
 * app-portage/gentoolkit) in order to detect such breakage.
 * 
 * Always study the list of packages to be cleaned for any obvious
 * mistakes. Packages that are part of the world set will always
 * be kept.  They can be manually added to this set with
 * `emerge --noreplace <atom>`.  Packages that are listed in
 * package.provided (see portage(5)) will be removed by
 * depclean, even if they are part of the world set.
 * 
 * As a safety measure, depclean will not remove any packages
 * unless *all* required dependencies have been resolved.  As a
 * consequence, it is often necessary to run `emerge --update
 * --newuse --deep @world` prior to depclean.

П.С. Генту как ни что другое подходит для новичков, т.к. отучает переустанавливать систему из-за какого-нибудь ШГ и заставляет платить за глупые ошибки временем.

placeholder
()

Xfce - если требования к ресурсоемкости... А так, KDE4 - по мне так очень удобный оконный менеджер... до этого сидел на Gnome2...с выходом 3 версии ушел окончательно на кеды... очень доволен:)

ElSuerte
()

docstore.mik.ua/manuals/ru/icewm/icewm­ru.html#toc6
quickcode.chat.ru/icewm/icewm­ru.html
mydebianblog.blogspot.com/2006/10/icewm.html.
avreg.net/howto_icewm.htm
konishchevdmitry.blogspot.com/2008/07/icewm.html
vectorlinux.osuosl.org/docs/vl50/vlfaq/icewm.htmt.

icewm

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