|
Не хвърляйте старите компютри
|
|
|
|
|
|
от Н. Антонов(24-01-2006)
рейтинг (79)
[ добре ]
[ зле ]
Вариант за отпечатване Цел на статията
Описаното тук решение не дава нищо оригинално. То е само пример за една от най-баналните и стандартни възможности на мрежово ориентираната графична система XFree86, използвана широко в повечето Unix системи и разбира се - в Linux. Цел на тази статия е да опише едно просто и бързо за реализиране решение, при което множество слаби машини използват централизиран сървър за визуализиране на графичен интерфейс, като се възползват всички ресурси на сървъра, в това число процесор, памет, скорост на твърдите дискове, дисково пространство, звукова платка и целия му хардуер изобщо, инсталиран и евентуално оптимизиран клиентски софтуер, т.е. KDE, OpenOffice, Mozilla и други подобни, в това число и шрифтове. Решението е реализирано с дистрибуция Debian GNU/Linux Sid (unstable), ядро 2.6.9, XFree86 4.3, използваните машини са само три, което е напълно достатъчно, за да се направят съответните изводи, а локалната мрежа е с капацитет 100Mbps. По-късно ще видим, че капацитетът не е толкова важен, тъй като информацията, която се трансферира през мрежата, е пренебрежително нищожна..
Предимства
Оставяме на последно място факта, че клиентските машини ще работят със скоростта на съвременна P4 система (да, наистина). При така реализирано решение вие инсталирате и настройвате целия използван софтуер само на една машина (т.е. на сървъра), създавате потребителски акаунти само на нея. От друга страна потребителите достъпват всичките си лични файлове и настройки отвсякъде по един и същи начин. Ако това не е идеалната мрежова среда за пълноценна работа между множество машини едновременно, здраве му кажи. Ако пък клиентските машини са прекалено много, за да бъдат поети от един сървър, можете да го разтоварите, като използвате втори или трети, приложите някои трикове с репликация и т.н., които не са предмет на тази статия. При всички положения е по-добре да се грижите за един, два или пет съвъра, отколкото за десет, двадесет или петдесет клиента.
Настройване на сървъра
В моя случай разполагам с един Intel P4 2.4Ghz, RAM 512MB DDR 400, Video OnBoard 16MB, HDD 2*80GB 8MB cache. На тази машина инсталираме целия софтуер, който планираме да ползваме. В случая освен стандартната базова система включваме метапакета x-window-system, който включва всичко, необходимо за работата на графичната среда. Добавяте KDE, OpenOffice, Mozilla, MPlayer и въобще каквото ви е на сърце, като не забраяте за любимите ви шрифтове. Акцентирам на KDE и логин мениджъра KDM, тъй като даденият пример тук използва именно неговите възможности. Стъпките, които е необходимо да извършим на сървъра, са обикновено две. Разбира се, приемаме, че сме настроили останалия софтуер е той е готов за използване, създали сме и съответния брой потребители.
- KDM
На първо място трябва да кажем на KDM да приема отдалечени потребители.
1. Редактираме файла /etc/kde3/kdm/kdmrc по следния начин. Намираме секцията [Xdmcp] и променяме реда Enable=false на Enable=true.
2. Редактираме файла /etc/kde3/kdm/Xaccess, като само разкоментираме следния ред:
#* #any host can get a login window
Редът трябва да изглежда вече така:
* #any host can get a login window
Втората стъпка правим с ясното съзнание, че нашият сървър е достъпен само в рамките на локалната мрежа. Ако същата машина има излаз към интернет, тя трябва да бъде защитена задължително с firewall, което не е предмет на тази статия.
3. Третата стъпка е да отворим файла /etc/kde3/kdm/Xservers и да махнем опцията -nolisten tcp от командата за стартиране на Х. Редът би трябвало вече да изглежда примерно така:
:0 local@tty1 /usr/X11R6/bin/X
4.Презареждаме конфигурацията на KDM:
/etc/init.d/kdm reload
- X Font Server
Защо ни е необходимо това? Това ни позволява да инсталираме необходимите ни шрифтове само на сървъра, без изобщо да ни интересува какви шрифтове има на клиентските машини, защото те на практика ще ползват шрифтовете на сървъра, като ги достъпват чрез X Font Server. В случая това е пакетът xfs, който е част от x-window-system. Настройките на xfs се правят от /etc/X11/fs/config, където посочваме пътя към директориите с необходимите ни шрифтове. Намираме реда no-listen = tcp и го коментираме, за да не се взима предвид. Ако пипаме по този файл, задължително трябва да презаредим шрифтовия сървър:
/etc/init.d/xfs reload
Настройване на клиентските системи
Една клиентска система, играеща ролята на Х-терминал, на практика се нуждае само от базова инсталация, като добавим и пакета xserver-xfree86 (в Debian). Дори не се нуждаем от всичко, което влиза в метапакета x-window-system. След като сме настроили /etc/X11/ХF86Config-4 да работи с видеоплатката и входно/изходните устройства на клиентската машина (т.е. мишка и клавиатура), трябва да изпълним само една единствена команда, за да се покаже пред нас логин мениджърът на сървъра. Преди това обаче, да не забравяме за шрифтовете;)
Приемаме, че имаме мрежа от клас 192.168.0.0/24, като сървърът ни отговаря на 192.168.0.1. Трябва да кажем на локалния X, т.е. Х-а на клиентската машина, който ще осигурява само достъп до видеохардуера ни, до мишката и клавиатурата, да чете шрифтовете през отдалечен шрифтов сървър. Отваряме файла /etc/X11/XF86Config-4 и намираме раздела Section "Files". Коментираме всички пътища към локални директории с шрифтове. В този раздел трябва да имаме само следния ред:
FontPath "tcp/192.168.0.1:7100"
Какво написахме тук? Казахме на нашия Х да си търси шрифтове чрез протокол TCP, от машината 192.168.0.1, на чийто порт 7100 слуша по подразбиране X Font Server.
Стартиране
За да можем да видим на клиентската машина графичния логин мениджър на сървъра, трябва да заредим Х, като използваме малко по-особен синтаксис, но преди това трябва да се уверим, че на системата няма стартиран локален графичен мениджър. За всеки случай правим следното:
update-rc.d -f xdm remove
/etc/init.d/xdm stop
Така ще сме сигурни, че xdm няма да се зареди повече. Сега вече стартираме Х по следния начин:
X :0 -query 192.168.0.1
В резултат, би трябвало да видим логин мениджъра на сървъра. Логваме се и си работим на сървъра така, сякаш сме седнали локално пред него. Можем да си пуснем филм, да слушаме музика. Разбира се, ако сървърът е в съседната стая, внимавайте да не изплашите някого;)
Стартирането на Х по този начин не се поддържа от init-скриптовете на системата, а въвеждането наръка е досадно и освен това изисква правата на root. Не е редно операторите на клиентските машини да влизат първо като root, да стартират Х и след това да се удостоверяват пред сървъра като обикновени потребители, нали? Най-интелигентният начин да автоматизираме този процес, е като си дефинираме собствено init-ниво във файла /etc/inittab. Например, добавяме следния ред:
x0:3:respawn:/usr/bin/X11/X :0 -query 192.168.0.1
След това променяме реда id:2:initdefault: по следния начин:
id:3:initdefault:
Записваме промените и презареждаме init:
init q
Извикваме нужното ни ниво или рестартираме (би трябвало да се зареди по подразбиране ниво 3):
telinit 3
Общи впечатления
На първо място се убеждаваме, че системата X Window притежава неподражаема гъвгавост и има огромни мрежови възможности, които не са за подценяване. Що се отнася до натоварването на сървъра, основното, на което се набляга, е консумацията на памет и повишената дискова активност, особено ако паметта недостига. В нашия случай сървърът разполага с 512MB, което е недостатъчно за три едновременни клиента, работещи с Mozilla, OpenOffice, KDE etc. Забелязва се повече от 150MB големина на използваната виртуална памет, като понякога се достига до 250MB! Това означава, че ако разполагаме с 1GB памет на сървъра, тези проблеми изчезват моментално. Натоварването на мрежата е нищожно. През цялото време между клиента и сървъра се трансферират някакви 50-60K/s, което е пълна символика за една локална мрежа;) Нямам никакви забележки към стабилността. Достатъчно е да се погрижим софтуерът на сървъра да е оптимизиран, заради което аз лично компилирам всичко от изходен код с помощта на apt-build. Пакетите са оптимизирани с флагове "mcpu=pentium4 -pipe -fomit-frame-pointer -ffast-math -floop-optimize". Това упражнение е ненужно на клиентските машини, тъй като на тях има само един стартиран процес XFree86 и консумират не повече от 60-70MB памет. С една дума, дори с 64MB вашите стари "таратайки" ще хвърчат като P4;)
Извод
Безспорно, чрез системата X Window имаме възможност да ползваме пълноценно всичко, което прилича поне малко на PC, било у дома или в офиса. Не е нужно на всеки две години да сменяме всички машини и да влизаме в ненужни разходи, нито пък е нужно да се грижим поотделно за софтуера на всяка една от тях. Достатъчно е да поддържаме една съвременна конфигурация, която да се отличава най-вече с повече памет и по-бързи дискове и така ще си осигурим всичко, като се възползваме от реалните многопотребителски и многозадачни възможности на операционната система Linux, при която едновременно много потребители могат да оплзват едни и същи програми, без да си пречат и дори без да знаят кой какво прави;) Достатъчно е само да пипнем два конфигурационни файла, за да изстискаме максимума от наличния ни хардуер.
P.S.Бих се радвал, ако някой допълни тази статия с използването на GDM/Gnome за същите цели.
<< Въведение в RSBAC, част I | Инсталиране на TrueType шрифтове в Gnome >>
|
|
|
|
|
леки корекции
От: kernel
На: 25-11-2004@23:55 GMT+2
Оценка: 1/НеутраленНа терминалите им трябва по-скоро root over
NFS за да не се инсталират/обновяват
поотделно.
Въпроса с звука не разбрах как го решаваш.
С описаното от теб по-скоро ще слушаш
музиката на сървъра ..
И mplayer по добре го изтрий от списъка с
приложения защото не е подходящото за
примерите които даваш(количеството трафик,
ползване на различните видео драйвери ..)
Поздрави
[Отговори на този коментар]
xdm info
От: SleepLess <sleepless< at >sexmagnet __точка__ com>
На: 26-11-2004@1:54 GMT+2
Оценка: 1/Неутрален Кои файлове трябва а се редактират ако се използва xdm вместо kdm? (спец за "Намираме секцията [Xdmcp] и променяме реда Enable=false на Enable=true.") благодаря
Редактиран на: 29-11-2004@1:34
[Отговори на този коментар]
По-добре да не се използва xfs
От: al_shopov <al_shopov__at__yahoo< dot >com>
На: 26-11-2004@7:30 GMT+2
Оценка: 1/НеутраленПрепоръчвам да не се използва xfs. Това е остарялата технология на core fonts и при нея е невъзможно използването на заглаждане на шрифтовете. Клиентите за X Window трябва да имат файлов достъп до шрифтовете. Възможно е те да бъдат споделени през NFS.
ал_шопов
[Отговори на този коментар]
Sound /(Video) ?
От: Митьо <mitio __@__ ucc__dot__uni-sofia__dot__bg>
На: 26-11-2004@8:07 GMT+2
Оценка: 1/Неутраленидеята наистина има почва у нас. Обаче съм се чудел, как се решава въпросът с музиката? Ясно е, че при стартиран mplayer на сървърът, sound-а ще излиза от машината където е mplayer-ът. Да предположим, че имам XClient и искам да ползвам XServer, който е в блока до мен. На клиенската машина имам video/sound карти. Тогава как мога да реша проблема с play-ването на музика?
[ps. извинете за тъпия въпрос :/]
[Отговори на този коментар]
За ползването на XFS
От: Н. Антонов <nikola__at__linux-bg< dot >org>
На: 26-11-2004@8:09 GMT+2
Оценка: 1/НеутраленХм, няма проблем със заглаждането на шрифтове при ползването на xfs. Не разбирам защо смяташ, че не работи. При мен поне работи. Доколкото ми е известно, самото заглаждане се прави от клиента.
Иначе безсспорно nfs може да се използва за всичко, така че и този вариант е напълно приемлив;)
[Отговори на този коментар]
Малко уточнение за "оптимизациите"
От: AstronoM <astronom__at__dir< dot >bg>
На: 26-11-2004@8:12 GMT+2
Оценка: 1/Неутрален Едно малко уточнение. Параметърът на командния ред -pipe не оптимизира кода, който създава компилатора, а по-скоро му помага да работи по-бързо, защото се използват канали за комуникация между отделните фази на компилацията вместо временни файлове. Взето директно от документацията към gcc 3.4.3 (http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Overall-Options.html#Overall-Options):
...
-pipe
Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.
...
Статията е добра, но би било добре да се разшири с повече информация. Не е споменато например, че и Windows работни станции могат да работят точно толкова успешно колкото и Linux такива. Като X сървър за Win32 може да се използва този който идва с cygwin (XFree86 за Win32), както и доста комерсиални X сървъри.
Спомням си, че преди време бях чел една статия, в която студенти и преподаватели от един американски университет са направили мрежа с около 100 стари компютъра (386, 486) в пълноценни работни станции за университетската библиотека, като за целта превърнали няколко по-мощни машини в графични сървъри. Разбира се за целта е използван Linux и X сървъра. Искам да попитам тук привържениците на M$, колко би струвало подобно решение със Windows и Remote Desktop? Разбира се не искам да отричам предимствата на RDP, защото вързката е кодирана, докато връзката между X клиента и X сървъра не е. Това също е добре да бъде упоменато в статията, защото именно поради тази причина описаното решение е най-подходящо за защитена с firewall локална мрежа.
Редактиран на: 26-11-2004@8:30
[Отговори на този коментар]
към: леки корекции
От: Н. Антонов <nikola< at >linux-bg< dot >org>
На: 26-11-2004@8:15 GMT+2
Оценка: 1/НеутраленТемата за root over nfs не е предмет на тази статия. Безпорно е по-доброто решение, но затова пък се реализира по-трудно, докато тук става дума просто за три реда в няколко конфигурационни файла.
Забележката ти за mplayer не е коректна. Посоченият от мен трафик е среден при нормално използване на системата, без пиково натоварване. Не съм си играл да гледам колко трафик поглъща гледането на филм, но със сигурност няма да е много, защото между машините се преточва минимално количество информация. Практически филмът се възпроизвежда на сървъра.
За звука не съм си играл, тъй като на клиентските машини няма звукова платка. Но проблемът може да се реши чрез използването на мрежова звукова система, каквито виждам, че има доста, само че нямам опит с тях.
[Отговори на този коментар]
към: * #any host can get a login window
От: Mitov <mitov< at >issp__dot__bas__dot__bg>
На: 26-11-2004@8:38 GMT+2
Оценка: 1/НеутраленМодифицирайте този ред:
* #any host can get a login window
по следния начин:
*.your.domain.name.bg #only hosts from your
domain
Разбира се, че reverse resolution трябва да
работи.
При нас използваме LTSP (Linux Terminal
Server Project) за 3 бездискови стари машини
(Pentium 1, 32-64 MB RAM, LAN + boot ROM),
бутваме ги по мрежата (кернел, LAN драйвер,
Х, графичен драйвер) и работят като Х
терминали. Крайният резултат е почти
същият;-))
[Отговори на този коментар]
Евала !!!
От: A3
На: 26-11-2004@10:11 GMT+2
Оценка: 1/НеутраленБраво, това е много актуално и полезно! Поне според мен! Чао
[Отговори на този коментар]
За mplayer
От: Hapkoc
На: 26-11-2004@11:01 GMT+2
Оценка: 1/НеутраленМисля, че забележката на al_shopov е уместна. Mplayer действително се изпълнява на сървър-а, но нали все пак картината от филма трябва да стигне по някакъв начин до клиентската машина. Очевидно този начин е през мрежата, а един видео поток определено не е нещо малко (да кажем 25 frames/s).
Може би греша, ако е така - не ме оплювайте моля, а ме поправете :-).
[Отговори на този коментар]
към: За mplayer
От: Н. Антонов <nikola__at__linux-bg[ точка ]org>
На: 26-11-2004@11:11 GMT+2
Оценка: 1/НеутраленМисля, че е логично при гледане на филм да се вдига натоварването на мрежата. Става дума за около 2 мегабайта в секунда при висококачествено .avi.
[Отговори на този коментар]
към: Mitov
От: Н. Антонов <nikola (a) linux-bg __точка__ org>
На: 26-11-2004@11:35 GMT+2
Оценка: 1/НеутраленДа, LTSP е яко нещо и мисля, че ще бъде голям принос, ако опишете подробно как го използвате.
Иначе целта на тази статия е да покаже как се постига нещо с цената на минимум усилия, без пачването на ядрото, без използването на бездисково стартиране от мрежата и т.н. Това са все неща, които са много по-мощни и функционални, но изискват и доста задълбочаване в материята.
[Отговори на този коментар]
LTSP
От: alabala
На: 26-11-2004@12:01 GMT+2
Оценка: 1/Неутраленето:
http://linux-bg.org/cgi-bin/y/index.pl?page=article&id=programs&key=349763084
При мен имам зала с 8 терминала и 1 LTSP server
terminal: Pentium 1, 32Mb RAM, 2 Mb Video Matrox, boot Lan card
server: Celeron 2 Ghz, 1024RAM, 80Gb HDD
Тъйкато се ползва КДЕ за десктоп то сърверчето малко издиша, препоръчвам сървера да е P4 и то с подръжка на хипертрейдинг и по-голяма кеш на CPU-to.
Пък ако имате нещо 2xCPU още по-добре.
Аз LTSP го позлзвам вече около 2 месеца и съм доволен.
[Отговори на този коментар]
Терминални сесии
От: Ivaylo Toshev <ivo< at >linux __точка__ itce __точка__ com>
На: 26-11-2004@12:13 GMT+2
Оценка: 1/НеутраленИзползването на XDMCP и X протокол за терминални сесии е наистина стара почти колкото Х.
Но както всяка идея търпи развитие, така и технологията и ползването на графични терминални сесии се разви особенно в последните години, откакто излезе Win2000 Server.
Или с други думи решението с XDMCP и Х не решава следните неща:
- Session disconnection: Т.е. отваряш сесия, след това "се откачащ" при което приложенията продължават да си работят. По някое време се закачаш от друга станция и си продължаваш и т.н.
- Local resource mapping: А именно прехвърляне на ком/USB портове и звук на локалната машина ( тук трябва да уточня, че по мрежата има проекти използващи network-pipe през SSH за тази цел);
- Възможност за връзка през наистина бавна мрежова връзка ( 33,6 Kbps ) - с Х протокол - това просто ще е мъчение.
И една забележка : споменатото натоварване от 50-60 Кб/с е мерено с колко на брой клеинтски машини и реално работещи едновременно приложения върху тях ???
Аз самия съм правил много експерименти и съм стигнал до извода, че за една сесия с нормална работа е необходимо между 100-150 кб/с, т.е. за 100 Mbps - не повече от 10, максимум 15 клиента и то ако работят предимно със статични приложения.
Засега добро решение може би ще се появи от FreeNX - www.nomachine.com - там обаче още не са решили съвсем проблема с disconnected sessions ( да можеш да се откачиш и след това да се закачиш, но с удивление ще забележиш, че когато си се откачил - всички приложения са спрели докато сесията е в disconnected state ).
-Друг проблем тук е че не е възможен "remote assistance" при решението на NX. За XDMCP и X протокола - там може да се намери решение с VNC, но пък ако се включи и VNC потоци по мрежата ....
[Отговори на този коментар]
speed
От: alabala
На: 26-11-2004@12:25 GMT+2
Оценка: 1/НеутраленМисля че с навлизането на гигабитов ethernet
проблема за потока към сървера няма да е проблем.
Вече повечето от новите дъна предлагат порт на 1000Мб.
Но още веднъж повтарям че е добре сервера да е нещо сероизно.
Минимум P4 ... добре е че цените на новите процесори падат. Все пак това не е IBM blade и струва 200-300$ за процесор.
[Отговори на този коментар]
Статията е страхотна!
От: fla
На: 26-11-2004@12:52 GMT+2
Оценка: 1/Неутрален
Лично според мен статията е написана като за хора не много навътре в материята. И като за такива е наистина страхотно написана - крата, ясна, точна, 3 реда корекции и готово! Смятам да я пробвам възможно най-скоро! :)
Относно коментарите за непълнота - ако се опишат подробности и разклонения, статията ще си загуби смисъла. Ако някой все пак реши да я допълва, нека го направи като втора статия, която да върви към тази, но не да я преработва.
Благодаря
[Отговори на този коментар]
Ре:xdm info
От: Румен Петров <help (a) roumenpetrov __точка__ info>
На: 26-11-2004@13:53 GMT+2
Оценка: 1/НеутраленВиж файла /etc/X11/xdm/xdm-config и съдържанието на директорията.
[Отговори на този коментар]
Re: Sound /(Video) ?
От: Румен Петров <help (a) roumenpetrov[ точка ]info>
На: 26-11-2004@14:04 GMT+2
Оценка: 1/Неутрален:)
Като стартираш nasd, esd или artsd с подходящи опции при клиента и укажеш това(т.е. конфигурираш) на player-ра стартиран на сървера.
[Отговори на този коментар]
Статията е много добра и полезна
От: Ivan
На: 26-11-2004@20:10 GMT+2
Оценка: 1/НеутраленСтатията е много добра и полезна. Браво. Преди може би 2 години бях провокиран от тази идея публикувана в Linuxgazette. За съжаление по ред причини не се стигна до реализация. Ще следя с интерес развитието на темата (дано има такова) и ще съм благодарен на всеки, който сподели опита с GDM, XDM. А ето и един линк http://www.kaszeta.org/rich/unix/xterminal/index.html
[Отговори на този коментар]
бих се радвал ако има о6те такива идеи
От: alexander <alex790316 __@__ abv< dot >bg>
На: 26-11-2004@23:22 GMT+2
Оценка: 1/НеутраленНе спираите да публикувате такива материали.Те са полезни не само за напредналите в тази област но и за нас на4инае6тите.Бих искал да нау4а пове4е по този и други вьпроси относно вьзможностите на "Линукс".
[Отговори на този коментар]
към: LTSP
От: Н. Антонов <nikola< at >linux-bg __точка__ org>
На: 27-11-2004@8:14 GMT+2
Оценка: 1/НеутраленДа, благодаря, спомних си за тази статия. Много е полезна.
Но LTSP наистина изисква повече задълбочени познания - nfs, пачване на ядрото, компилация, изисква и по-специален хардуер (LAN карти с възможност за boot) и т.н. Безспорно е много е по-сериозно, но затова пък не може да се изпълни за 5 мин. без никакви специални средства и познания, освен тези, които са необходими на всеки потребител, за да си инсталира стандартна дистрибуция и да си настрои Х;)
[Отговори на този коментар]
Локални процеси и процеси на сървъра
От: zeon
На: 27-11-2004@16:31 GMT+2
Оценка: 1/НеутраленА възможно ли е все пак някои процеси да си се стартират на локалната машина, докато други се изпълняват на сървъра?
Имам предвид, че 5-10 едновременно пуснати филма доста биха затруднили дори P4 сървър.
Така че, възможно ли е да се направи така, че някои програми да си се изпълняват на сървъра, а други на локалната машина (mplayer), ако дупуснем, че тя има потенциал за това?
Идеята е да постигнем някакъв компромис между това, което се изпълнява на сървъра и това, което се изпълнява на клиентската машина.
[Отговори на този коментар]
info
От: pepsi <pepsi __@__ net-surf< dot >net>
На: 27-11-2004@19:58 GMT+2
Оценка: 1/НеутраленWyprosa mi e: kak moje towa jivotno da se izpolzva v Internet cafe ili Game zala? shte sym blagodaren ako aftora na statijata ili vseki kompetenten po vyprosa da mi otgovori na maila! 10x!
[Отговори на този коментар]
LTSP за 2 мин
От: alabala
На: 28-11-2004@15:56 GMT+2
Оценка: 1/НеутраленМоже всеки да пусне LTSP за 2 мин !!!
Ако си вземе Knoppix 3.6 може да си пусне готов LTSP сървер направо от live CD
След което да си направи бутващи дискети:
http://www.rom-o-matic.net/
За клиентските станций.
Ето как става за две минути ...
[Отговори на този коментар]
Как да не....
От: !ССТАНЕВ!
На: 30-11-2004@23:16 GMT+2
Оценка: 1/НеутраленКак пък да не падна от смях, да не хвърляме старите компове, че линукс вървяло бързо, било пробвано на Пентиум 4 (ЧЕТИРИ)?!?!?!?
На 210МХц с 64 РАМ (което наистина си е вече стар комп), Windows 2000 върви в пъти по- бързо от Mandrake някой си (забравил съм вече), ако изобщо може да се каже, че върви (разгъване на 6 меги архив за половин час бие рекордите на ХТтата в училище).
Аве, да не изреждам, вече се посмях и ме домързя.
[Отговори на този коментар]
къвм: Как да не...
От: Н. Антонов <nikola __@__ linux-bg __точка__ org>
На: 1-12-2004@11:12 GMT+2
Оценка: 1/НеутраленМой човек, сбъркал си сайта, това е сайт за компютри и Линукс, ти не си за тук. Твоята посока е натам - http://web.logos-bg.net/linuxbg/agrocenter.jpg .
:)
P.S. Изобщо нямам намерение да отговарям сериозно на неадекватни коментари, писани от хора, които даже не могат да проумеят за какво става въпрос.
[Отговори на този коментар]
Малеее
От: ahahah <jaja (a) yahoo[ точка ]com>
На: 1-12-2004@23:47 GMT+2
Оценка: 1/Неутрален възможно ли е все пак някои процеси да си се стартират на локалната машина, докато други се изпълняват на сървъра?
Имам предвид, че 5-10 едновременно пуснати филма доста биха затруднили дори P4 сървър.
Така че, възможно ли е да се направи така, че някои програми да си се изпълняват на сървъра, а други на локалната машина (mplayer), ако дупуснем, че тя има потенциал за това?
Идеята е да постигнем някакъв компромис между това, което се изпълнява на сървъра и това, което се изпълнява на клиентската машина.
МАЛЕЕЕ ама аз имам амд 500 което ми пуска филми на 20 машини??? коментар???
[Отговори на този коментар]
Към: Малеее
От: Н. Антонов <nikola __@__ linux-bg< dot >org>
На: 2-12-2004@8:46 GMT+2
Оценка: 1/НеутраленВъзможно е, но не и чрез това решени, което съм описал в тази статия. То е максимално просто и може да се реализира от всеки, който е успял да си инсталира Линукс и да си настрои Х само с пипане в един два файла. Нищо повече. Няма възможностите и разчупеността, а също скалируемостта на проекти като LTSP например. Иначе на въпроса ти конкретно не мога да отговоря, защото не съм компетентен до такава степен. Може би трябва някой друг да сподели, ако е успял да реализира подобни задачи със споделяне на натоварването между сървъра и клиента.
[Отговори на този коментар]
486!!!
От: milen40
На: 30-12-2004@8:53 GMT+2
Оценка: 1/Неутраленпробвах да направя подобно нещо :сервер п3 ,клиент 486, филмите не вървят на видео с 1мб (мплейъра се пуска на сервера):)) тва е моята констатация :))
[Отговори на този коментар]
Видео
От: Nik
На: 9-02-2006@0:45 GMT+2
Оценка: 1/Неутраленняма как да стане номера да гледате видео в този случай и да не се сблъскате с маса и два стола ограничения. Х-сървъра няма свойството да компресира (много) ефективно предаваната картина. Особено ако/като се вземе предвид frame rate / refresh rate на един нормален PAL и на да речем набор на текст с 5 символа в секунда. Не, графичната среда няма за идея да прехвърля филми, та по-добре забравете за PAL и HDTV. Може и да успеете да прекарате нещо с VCD или SVCD резолюция (320х240, 352х288) през това чудо, ама не разчитайте, че ще е перфектно.
Останалото е ясно - Firefox и OpenOffice.org работят безотказно и на P133, просто им трябва повечко време, а на Вас - волско търпение и мноого кафе. Ако ги стартирате на Р4 нещата са доста по-гладки, пък и обема данни, които прехвърля Х-сървъра за да ги обслужи е пренебрежимо малък в сравнение със скоростта на мрежата.
[Отговори на този коментар]