Что вы! Это лишь означает, что я попал если и не в 10-ку, то в 9-ку уж точно. И, как видите, Nulex-а, что называется, понесло. Хех, на это и был расчет, в конце концов. Единственное о чем я забыл: что и мне придется тратить много времени на ответы. Сейчас, задним числом, я это уже понял, поэтому хоть ответ и все еще длинный, в нем мало примеров, нету многих ссылок, и вообще не хватает конкретики. С другой стороны, зачем стараться ради очередного витка вечного холивара "Винда вс ЛинАкс" ? Дефрагментатор господина Kolivas-а - это шелл скрипт, который дефрагментирует с помошью cp/mv. Иногда это сработает. Но это нельзя назвать полноценным дефрагментатором, который работает на уровне фс, хотя бы потому, что когда диск почти заполнен, свободные блоки как были разбросаны, так и останутся, сколько ни перезаписывай. Shake - как я понял с ихнего сайта, тоже просто перезаписывает файлы. Может немного умнее, чем упомянутый выше шелл-скрипт, но это все равно не на уровне фс. Кроме того, мне не нравится, что shake что-то пишет в xattr файлов. Он должен просто перемещать блоки чего-то там (неважно), а не устраивать БД у меня на фс. А вот e4defrag - да, это что-то похожее на полноценный дефрагментатор. Я про него забыл, спасибо, что напомнили. Что ж, браво, наконец-то у ext появился дефрагментатор. Прошло какие-то 10 лет с релиза ext3.. А также, к слову, раз уж вы привели ту ссылку, то может вы заодно ответите мне на вопрос: зачем запускать git, configure и make из-под sudo? Насчет того, падает ли производительность - не сомневайтесь, еще как падает. Надо всего лишь подождать нужного количества фрагментов, разбросанных по всему диску. Это более, чем реально, если диск почти всегда заполнен под 100%. Не сразу, конечно, но результат гарантирован. При хорошей фрагметации (несколько кб на фрагмент) скорость чтения упадет до 5-10мб/с. Примеров не будет. В качестве доказательства я вам только скажу, что как бы вы не размещали файлы на пустом диске, последующие удаления, и записи все равно сделают свободное место фрагментированным. А значит, когда появится достаточно большой файл, он соберет все эти фрагменты в себе. Это невозможно предотвратить при создании файлов, тк будущие действия пользователя просто неизвестны. Что-то вам везде утята мерещатся. Травка? Или валидола объелись? Я ждал этого вопроса. Открою вам большой секрет - в винде также, как и в вашем любимом линуксе, большинство проблем решается без переустановки. Но меня не интересуют ни переустановки, ни обновления. К сожалению, сказать, что вы делали не так, я не могу, тк я не знаю, что вы делали. Зато я предлагаю вам ответить на обратный вопрос: исправить то, что я делал не так. И, я вам гарантирую, пары часов не хватит. Итак, начнем, пожалуй, с терминала. Видимо, это общая фича всех терминалов, написанных VTE-виджете, но если в tmux-е разбить окно вертикально на два, то копипаст мышкой из правой половины останавливается, не доходя до конца строки, либо сразу выделяет все до конца. Одним словом, выделить одну строку почти до правого края экрана невозможно. Думаю, не стоит говорить, что это исключительно неудобно, и делает вертикальное разбиение почти бесполезным. Но в xterm все отлично работает. Вот только проблема в том, что настройка xterm-а немного сложнее, чем потыкать в графических настройках гномо-терминала. И тут, в связи с появлением xterm-а, возникает вопрос про X resource. Точнее, про вывод команд listres и viewres:
$ listres Object
WidgetClass Instance Class Type
----------- -------- ----- ----
object: Object
Object destroyCallback Callback Callback
здесь все более-менее понятно. А если вот так
$ listres -variable object
Variable Instance Class Type
-------- -------- ----- ----
object: object
object destroyCallback Callback Callback
то уже непонятно: что такое variable ? Это объект соответствующего класса? Тогда кто его создал? Ведь listres показывает иерархию классов доступных виджетов, те здесь нету никакого приложения (типа xterm), которое могло бы создать объекты. Если это не объект, то что это? Продолжение следует.. Теперь перейдем совсем к другой теме: когда-то я пользовался Thunderbird-ом. Он был вцелом ничего, только запуск внешнего редактора для написания письма там работал как-то "криво" (не помню точно, но то ли какой-то полузаброшенный плагин, то ли какой-то полухак). Кроме того, я не нашел (не очень искал, если честно) способа, отметить ветку сообщений (в рассылку мейллиста), как "неинтересную", чтобы все новые письма _этой_ ветки автоматически помечались как "прочитанные". Зато я услышал, что в claws-mail все это есть в "стандартной" поставке. Я его попробовал - и правда, все есть. Казалось бы, вот оно счастье, но не тут-то было. Я заметил, что письма не "приходят" в claws-mail пока я не нажму кнопку "Get mail". Видимо, причина этого в том, что он не поддерживает IMAP IDLE. И разработчики отказались добавлять эту возможность, несмотря на многочисленные просьбы пользователей. Там есть таймер, через который он может запрашивать сервер о новых письмах, но это все-таки не то. Может быть, это все еще можно исправить с помощью каких-то дополнительных программ. Продолжение следует.. И снова сменим тему. Есть старая "фича" гномовского power-manager: изменять яркость сразу на несколько делений. Как я понял, это происходит из-за того, что при нажатии кнопок яркость изменяют сразу несолько "программ": одна из них это ядро (acpi?), вторая - собственно power-manager. В результате получается на 2-3 деления. Это очень неудобно, тк из 16 делений у меня остается 5. Где-то в багзиле гнома был непринятый патч. Говорят, в power-manager-е xfce для этого бага сделали workaround в виде "холостого хода": когда power-manager только показывает "менюшку" изменения яркости, но не изменяет ее сам, надеясь, что этот "второй кто-то" все сделает. В первом случае, патч должен быть применен (или переписан) под текущую версию гномовского power-manager и пакет пересобран, во втором - гномовский менеджер в гномо-сессии заменен на xfce-шный. Продолжение следует.. Есть старый "баг" X-ов: переключение раскладки при _нажатии_ кнопок, а не при их отпускании (как в винде). Это становится исключительно неудобно, если вы сделали переключение раскладок, допустим, Alt+Shift, а потом сделали в каком-нибудь гномо-терминале перключение вкладок Alt+Shift+цифра. В таком случае, при переключении вкладок у вас будет еще и язык переключаться. В багзиле xorg был патч. Его не приняли, потом.. в общем, не буду пересказывать, скажу лишь, что чтение комментов этого бага доставляет. В багзиле убунты тоже есть соответствующий багрепорт. Там патч приняли. Не знаю, вошел он в пакет убунты или нет, но, даже если вошел, то вряд ли он есть в других дистрах (например, в Дебиане). Это значит, что патч надо найти, применить, пакет пересобрать.. Продолжение следует.. И, напоследок, например, вот такое. Снапшоты lvm-а иногда можно использовать, чтобы сохранить предыдущее состояние фс (если она не поддерживает снапшоты внутри фс, как zfs). Проблема в том, что сделав таким образом "временный" бекап, можно случайно записать на origin LV данных больше, чем размер CoW-устройства снапшота. Тогда снапшот станет invalid, и "временный" бекап будет потерян. Возможная идея заключается в том, чтобы когда CoW-устройство почти переполнено послать suspend (см. dmsetup(1) suspend) на origin LV и снапшот. Тем самым, возможно, дав пользователю возможность увеличить CoW-устройство снапшота до того, как оно переполнится. Это лишь идея, может быть так сделать нельзя. Кроме того, suspend на origin LV - не очень хорошая идея сама по себе, но тем не менее, возможно, добавив какие-нибудь таймеры, из этой идеи можно сделать что-то пригодное хотя бы для домашнего использования. Продолжение вряд ли следует.. Ну, думаю, хватит. Этот список можно продолжить в бесконечность (по крайней мере, пока что мне так кажется). Не хотите ли довести до _конца_ решение предложенных выше задач? Впрочем, я вам дам совет: если вам не совсем нечего делать, то вы должны отказаться. И это будет абсолютно правильный ответ. Вот именно, что нет! Для уровня чайника или мартышки чтение документации должно быть либо вовсе не нужно, либо сведено к нескольким строчкам. Если это не так - это плохая программа (точнее с плохим интерфейсом). Конечно, есть и исключения, но программы, расчитанные на "всех", явно не относятся к этим исключениям. Почему "порог начала использования" должен быть низким? Очень просто: чтобы я смог начать использовать программу как можно быстрее. От этого преимущества получают все: я, не тратя много времени на изучение программы, могу ее сразу попробовать и, возможно, понять, что это вообще не то, и продолжать не имеет смысла. Если же это "то самое", то я всегда могу постепенно, когда будет время и желание, увеличивать свою "квалификацию" в использовании данной программы. Разработчик же получает преимущество в том, что пользователь уже пользуется его программой. Для сравнения, если даже для базового использования требуется изучение большого количества документации, то пока пользователь все это читает, он использует какой-то _другой_ аналогичный продукт. Это не говоря уже про то, что кто-то, взглянув на объем документации, сразу откажется от программы. Кому нужны ваши вопросы! RTFM - и это весь ответ на 99% всех вопросов на всех форумах. И, самое главное, это абсолютно правильный и совершенно бесполезный ответ. Его правильность делает бессмысленным большинство вопросов. Его бесполезность делает, порой, поиски ответов невероятно долгими. И именно поэтому софт должен работать приемлимо "из коробки" - чтобы во время бесконечных поисков ответов, можно было продолжать делать что-то еще, используя этот софт. Другими словами, чтобы очередная поломка не стала "блокирующей" для всего остального. Правда, умные люди придумали решение лучше: чтобы с одной стороны не повторять 1001 раз ответы на одни и те же вопросы, а с другой - не посылать на 4 буквы, написанные выше, - StackOverflow . Ай-яй-яй, это вы зря. Полноценных ДЕ, в которых в каком-то виде есть все: панель управления, интеграция приложений, работа "из коробки" - только два: КДЕ и Гном. Вот только Гном3 в его нынешнем состоянии - это просто игрушка. Гном2 - не поддерживается. Форки вряд ли могут быть каким-то надежным решением, тк энтузиасты никогда не заменят апстрим. Тем более для такого большого проекта. "Легкие" ДЕ слишком сильно уступают по возможностям "из коробки", как КДЕ, так и Гному. Часть этих недостающих возможностей, конечно, можно допилить напильником, от части - просто отказаться, вот только все это требует немало времени. Одним словом, из полноценных ДЕ, поддерживаемых апстримом, КДЕ - единственный. Что такое YOBA я не знаю. И, говорю заранее, в гугле искать не буду, и можете меня туда не посылать - если вам интересно, чтобы я понял ваш ответ, найдите ссылку сами или напишите объяснение. Но, в любом случае, Гном3 требует 3Д-ускорение (для не fallback режима). Так что об играх речь вообще не идет. Не ешьте много. Вам уже и сейчас утята мерещаться, а так и сами утеночком станете. Рискну предположить, что whois хотел подробности по поводу "памяти и мозгов". Что такое "мозги" остается только догадываться, но если под проблемами с памятью вы имеете в виду то, что в ХР не видно 4гб памяти, - то это не такая уж и проблема. Учитывая, что сам ХР расходует намного меньше 7-ки, и 3.2 (или сколько там доступно?) хватит для офиса и фф с сотней вкладок (хотя зависит от содержимого, конечно). Фрагментация не редкая вещь на винде. Скорость чтения 10мб/с получить вполне реально. Рецепт аналогичный тому, что был выше.
