Със Slackware - май нищо. Ако беше с дистрибуция, която има контролни суми на инсталираните пакети:
1. Дърпаш мрежовия кабел.
2. Зареждаш от спасителен диск.
3. Сравняваш контролните суми на ВСИЧКИ пакети.
4. Пакетите, на които контролните суми се различават, са им пипани файловете.

РЕДАКЦИЯ: Как се прави тази проверка за системи, които ползват RPM, детайлно е описано от Весо Колев в http://www.linux-bulgaria.org/webarchive/2005/Mar/33036.html

[Цитат]

Цитат

...но просто ми беше интересно да попитам дали има начин за гарантиране на ресурси макар че като се замисля това едва ли е възможно на еднопроцесорна архитектура.

Възможно е. За това си има операционни системи за реално време (real time) като QNX. Линукс не е с такава архитектура, но ако не ме лъже паметта имаше едни кръпки, които предоставяха такива екстри за вградени (embedded) устройства.

[Цитат]

Цитат

Май проблема е в gtk2 библиотеките.

Не е в тях, защото  gimp също е свързан динамично с gtk2, а пък бързите клавишни комбинации на кирилица си вървят в него.

Силно подозирам някой изпортен конфигурационен файл. Основание за това ми дава необходимостта да се редактира /etc/X11/xkb/symbols/pc/pc с кръпката http://bugs.kde.org/attachment.cgi?id=5740&action=view за да работят win-клавишите като модификатори.

[Цитат]

Цитат

Също така ако сте срещали свестен инструмент за администриране на pgsql - уеб базиран или multiplatform (все пак ми трябва в работата, а там освен сървърите всичко е опрозорчено) кажете.

pgAdmin III is a powerful administration and development platform for the PostgreSQL database, free for any use. The application is running under GNU/Linux, FreeBSD and Windows 2000/XP.
http://www.pgadmin.org/

http://www.linux-bulgaria.org/webarchive/2005/Feb/32887.html

[Примерен код]

В SUSE 9.1 mozilla 1.7.8 e динамично свързана с gtk2, XFree86 4.3.99,
а десния алт си превключва безпроблемно. Всъщност безпроблемно, ако забия

Примерен код

Option       "XkbOptions" "grp:toggle"

в конфигурационния файл на X, иначе не мога да го избера в контролния център на KDE. Обаче след като съм го сложил в конфигурационния файл, контролният център надлежно показва ISO_Next_Group като превключвател на клавиатурната наредба.

[Примерен код]

Аз съм със SUSE и KDE и също не мога да реша този проблем. Откоментарих реда ! $nonlatin в /etc/X11/xkb/rules/xfree86, xev ми дава един и същи код за Ctrl+C и Ctrl+ъ.
setxkbmap -v 10 дава:

Примерен код

Applied rules from xfree86: model:      pc104 layout:     us,bg variant:    ,bds options:    grp:toggle Trying to build keymap using the following components: keycodes:   xfree86+aliases(qwerty) types:      complete compat:     complete symbols:    pc/pc(pc104)+pc/us+pc/bg(bds):2+group(toggle) geometry:   pc(pc104)

Кирилизирал съм се през XF86Config

Примерен код

Section "InputDevice"   Driver       "Keyboard"   Identifier   "Keyboard[0]"   Option       "XkbModel" "pc104"   Option       "XkbLayout" "us,bg"   Option       "XkbOptions" "grp:toggle"   Option       "XkbVariant" ",bds"   Option       "XkbRules" "xfree86" EndSection

Програмите на KDE хващат бързите комбинации, след като отметнах Include latin layout в контролния център (сега виждам, че опцията е неизбираема, след като промених nonlatin в  /etc/X11/xkb/rules/xfree86).
Някакви идеи?

Койотът e много добър. От пакета, който може да си свалиш от http://www.coyotelinux.com/downloads/channel.php?ChannelID=5 си костюмизираш каквото ти трябва.

Ако това не те реди, виж каталога на dmoz - можеш да избираш между 30 дистрибуции, които се събират на дискета.

Виж също така и FreeSCO - даже имаше статия на този сайт.

Captive e библиотека за четене и писане по NTFS файлова система, която използва оригиналния NTFS драйвер на Microsoft. Авторът спря да я поддържа миналата година заради непрестанните  промени на двоичния интерфейс в ядрото.
За да я подкараш, ти е необходима поддръжка на LUFS в ядрото. За съжаление, именно поради гореспоменатите непрестанни промени това не е тривиална задача.
Най-добре разгледай сайта на проекта. Желая ти успех!

[Цитат]

time kuickshow 3977-4.jpg
real    0m11.162s
user    0m4.963s
sys     0m0.419s

time gimp 3977-4.jpg
real    0m40.463s
user    0m11.189s
sys     0m3.625s

като самия gimp стартира за 6-7 секунди (това не е първото му стартиране! при първото стартиране стартирането+зареждането на картинката отнемат 47 секунди ). Отворената картинка и gimp заемат заедно ~210 MB, с kuickshow ~150 MB
Преди отварянето заетата памет е 300MB, така че и в двата случая не стигам до ползването на суоп.

Машината e Athlon  XP 1800+ (1541 MHz), 512 MB RAM, 1 GB суап.

Цитат

Явно Gimp-a не става за обработка на големи файлове.

Наистина, увеличението става по-бързо в kuickshow, отколкото в gimp, но при скролирането не виждам някаква разлика във времената. Откъдето и да го гледаме обаче, gimp и kuickshow не са в една категория - gimp предлата доста повече функционалност.
Аз лично съм обработвал и по-големи изображения с gimp и субективното ми мнение е, че той е по-бърз и по-стабилен от photoshop при обработка на много и големи изображения. Така че твоето заключение е може би малко подвеждащо.

[Цитат]

Цитат

И ако е възможно,ще ми вървят ли по-старите DOS-овски  игри а и не само те , на LINUX-а ?

Повечето ще вървят, благодарение на dosbox

[Примерен код]

При мен е точно така:

Примерен код

sava@williams:~> locale LANG=bg_BG.UTF-8 LC_CTYPE="bg_BG.UTF-8" LC_NUMERIC="bg_BG.UTF-8" LC_TIME="bg_BG.UTF-8" LC_COLLATE="bg_BG.UTF-8" LC_MONETARY="bg_BG.UTF-8" LC_MESSAGES=POSIX LC_PAPER="bg_BG.UTF-8" LC_NAME="bg_BG.UTF-8" LC_ADDRESS="bg_BG.UTF-8"LC_TIME=bg_BG.UTF-8 LC_TELEPHONE="bg_BG.UTF-8" LC_MEASUREMENT="bg_BG.UTF-8" LC_IDENTIFICATION="bg_BG.UTF-8"

В  ~/.bashrc имам следното:

Примерен код

export LANG=bg_BG.UTF-8 export LC_MESSAGES=POSIX

На теб ти трябва само да добавиш

Примерен код

LC_TIME=bg_BG.UTF-8

в ~/.bashrc и да рестартираш KDE.

[Цитат]

Влез в BIOS-a при стартиране на компютъра и виж каква честота е зададена.

Цитат

Щото си взех памет PQI 3200 512 MB DDR  на 400Mhz а досега бях с PQI 256MB 266Mhz. Искам да разбера работи ли по-бързо или не. Дъното ми е Gigabyte 7VA KT400.

Това значи, че в момента честота е 266MHz. Никакво подобрение няма да получиш, ако просто замениш чиповете.
От друга страна, дъното ти поддържа максимална честота 333 MHz, така че това е максималното, което  можеш да изстискаш. ВНИМАНИЕ! Когато го пуснеш на такава честота, остави само новата 400 мегахерцова памет! Със старата няма да тръгне, или по-лошо - може да стане някоя мизерия.
Ако искаш да работиш и с двата модула, тогава не трябва да променяш текущата честота.

[Цитат]

Цитат

А това че системата е проектирана да използва максимално свободната памет няма нищо общо в случая. Цялата свободна памет се използва само за дискови буфери, т.е. кеш. Тези буфери се заделят от ядрото, не от userland процесите, и се заделят само в RAM, никога в swap. И при недостиг на RAM въпросните буфери се записват обратно на диска (ако се налага) и се освобождават. Само това се има предвид под "максимална употреба на свободната памет". Иначе по правило колкото по-малко памет ползва една програма, толкова по-добре.

Имах предвид, че повечето (разбирай - почти всички) потребителски програми са написани да използват максимално агресивно паметта. Ричард Столман казва следното по въпроса: "In programs for which handling very large files was not crucial, we encouraged programmers to read an entire input file into core, then scan its contents without having to worry about I/O.These decisions enabled many GNU programs to surpass their Unix counterparts in reliability and speed." [Ние окуражавахме програмистите да изчитат целия входен файл за програми, където поддръжката на много големи файлове не е критична, и след това да работят с него без да се притeсняват за входно-изходните операции. Тези решения направиха програмите на GNU по-бързи и по-надеждни от конкурентните им в Unix. ]

Това, че ядрото се стреми да използва максимално свободната памет е просто следствие на горния принцип. Разбира се, "много голям файл" е променливо понятие - по времето, когато се е изказал Столмън, 1МБ дисково пространство е смятано за огромен обем.

В София - Националната библиотека "Св. Кирил и Методий", копирните услуги. Отдавна не съм ходил, но мисля, че още печатат върху тениски.