Pēteris Caune
 
[Most Recent Entries] [Calendar View] [Friends View]

Wednesday, July 14th, 2004

    Time Event
    10:40a
    Nu tik būs

    Nu tik gāzīšu, nu tik instalēšu!

    Fedora Core 3 Test1
    11:41p
    Remote control

    Šī ir viena no idejām, kas ātri rodas, ātri (un parasti nepilnīgi) realizējas un ātri aizmirstas. Pusstunda izpētes darbu, stunda realizācijai.

    Problēma

    Dienas lielāko daļu esmu prom no sava "mājas" datora, bet arī pusdienlaikā labprāt vēlētos zināt, ar ko tas nodarbojas.

    Risinājumi?

    Lai attālināti kontrolētu datoru, ir lietojami daudz un dažādi varianti, piemēram, lietojot VNC, slēdzoties klāt terminālim - ar telnet/ssh/PuTTY/whatever. Ja jāslēdzas pie Windows datora - var lietot kādu trojāni vai kādu speciāli rakstītu attālinātās administrēšanas programmu.

    Iespēju it kā netrūkst, bet problēma slēpjas ugunssienās. Tās ir veselas divas un abus datorus-partnerus ierobežo katru no savas puses. Nav iespējams pieslēgties ne tieši, ne "atmuguriski". Droši vien, ka šādām situācijām ir kas īpašs un ļoti viltīgs jau izdomāts, bet es šovakar uzrakstīju un lielā priekā izmēģināju "sistēmu", kas nodrošina attālinātu komandlīnijas pieeju -

    Tā kā abi datori (klients un serveris) redz uz āru, bet no ārpuses nav redzami, jāņem palīgā kādu trešo - starpnieku, kas atrodas ārpusē. Starpnieks saņems klienta sūtītos pieprasījumus, nodos tos tālāk serverim, saņems apstrādes rezultātus no servera un nodos tos atpakaļ klientam. Klients slēdzas pie starpnieka pēc vajadzības, bet serverim nākas slēgties pie servera ik pēc noteikta laika intervāla, jo viņš jau nevar zināt, kad klientam kaut ko savajadzēsies. Ja nesen ir bijis kāds pieprasījums, šis intervāls ir īss (1-2 sek.), savukārt, ja sen nekas nav bijis jādara - garāks (15 sek.). Tādējādi, klients sākumā aizsūta kādu pieprasījumu, lai serveri "pamodinātu" un pēc vidēji 7 sekundēm var sākt normāli strādāt.

    Ko tad es īsti uztaisīju - vēl jau īsti neko rādāmu, viss kā vienmēr zaļš, bet lietot jau var.

    Serveris

    Tātad, servera pienākums ir ik pa laikam slēgties pie starpnieka, uzzināt, vai nav kas jādara, ja ir, izdarīt un atgriezt rezultātus. Komunikācijai tiek lietots HTTP protokols. Nekā sarežģīta - maza 40 rindiņu Python programmiņa to visu paveic. Tiesa, viņai vēl jākļūst krietni gudrākai, bet ir un strādā.

    Starpnieks

    Starpnieka pienākumi - saņemt klienta pieprasījumus un atgriezt apstrādes rezultātus, apstrādāt servera komandu pieprasījumus, apstrādāt servera atgrieztos rezultātus. Tā kā tiek lietots HTTP protokols, starpnieks atrodas ārpusē, klientam ir iecerēta tīmekļa saskarne - starpnieku būtu ļoti saprātīgi rakstīt PHP. Starpnieka skripts, ja neskaita HTML, arī aizņem tās pašas 40 rindiņas.

    Klients

    Klientam starpnieks nodrošina tīmekļa saskarni, un viss, kas klientam vajadzīgs - pārlūkprogramma.

    Darbībā

    Šādi šobrīd izskatās klienta saskarne:

    Shell

    Servera darbības protokola paraudziņš

    fetching command ..
    processed.
    fetching command ..
    processed.
    fetching command ..
    processed.
    fetching command ..
    executing: df
    server response: ['ok']
    processed.
    fetching command ..
    processed.
    fetching command ..
    executing: ls
    server response: ['ok']
    processed.
    

    Kopsavilkums

    Man jau patīk. Uztaisīšu drusku labāku (nenokarināmāku) servera galu un drošāku komunikāciju (nebūtu gudri sūtīt atklātā tekstā "su; ...." komandas) un sākšu lietot. Ar minimālām izmaiņām var dabūt arī WAP saskarni - tātad vēl var drusku paciesties līdz Linux-enabled telefona pirkšanai.

    11:41p
    Kārtējā ideja

    Ar šo esmu nedaudz iesprūdis, un sāku jau lēnām padoties, bet lai nebūtu tikai pačakarēts laiks, izstāstīšu jums arī.

    Ideja: Uzbūvēt programmu, kuru varētu lietot kā balto tāfeli - ātrām skicēm, piezīmēm, vilktām ar peli. Programmai paredzēts būt ar caurspīdīgu fonu, un aizņemt darbvirsmas no ikonām brīvo laukumu - tātad, varētu brīvi rakstīt uz darbvirsmas.

    Šim nolūkam diemžēl nevar būvēt GDesklets komponenti. GDesklets komponentes lielākoties nodrošina informācijas attēlošanu un satur visai skopas interaktivitātes iespējas.

    Lietoju Gnome, vienīgā Linux vidē noderīgā man zināmā valoda ir Python, tāpēc nolēmu cīnīties ar GTK2, Python un PyGTK. Tālāk neizplūdīšu garās detaļās, tikai uzskaitīšu, ko darīju -

    1. Atradu PyGTK tutoriāli
    2. Uzinstalēju Glade (GTK2 saskarnes zīmēšanai), gnome_*_devel pakotnes
    3. Sekojot tutoriālim, uzbūvēju vienkāršu GTK2 programmiņu (tas tiešām nav pārāk grūti, it īpaši, ja ir pieredze ar citām vizuālajām izstrādes vidēm, manā gadījumā - Delphi un VB)
    4. Izcīnījos ar GTK DrawingArea komponenti
    5. GTK paraugos atradu scribble.py, programmiņu, kas dara gandrīz to, kas man vajadzīgs
    6. Kaut kā jādabū caurspīdīguma iespējas. Atvilku, uzkompilēju, uzstādīju DirectFB
    7. Pārstartējos, izmantojot VESA Framebuffer režīmu (tagad man ir 1024x768 konsole 8-)
    8. Uzkompilēju, izmēģināju DirectFB paraugus
    9. Atvilku XDirectFB
    10. čekoutoju xc komponenti no x.org CVS

    Kamēr šo rakstīju, visai ilgais čekouts ir galā, jāiet mēģināt uzkompilēt XDirectFB X serveri. Tomēr, kā jau teicu, sāku jau padoties, jo izskatās, ka problēmas tikai sākas - sākot lietot XDirectFB X serveri, salūzīs milzums citu lietu, piemēram, maz ticams, ka vairs varēšu skatīties filmas eksotiskajos kodējumos. Kā arī, tā kā DirectFB nepiedāvā dzini, kas izmantotu nVidia GeForce grafikas paātrinātāju, jālieto krietni lēnāko VESA režīmu (!(3D spēles)). Un vispār, augšā aprakstīto programmu man negribās tik ļoti, lai tai tērētu vēl vairāk laika.

    << Previous Day 2004/07/14
    [Calendar]
    Next Day >>

Paviānu štelles   About Sviesta Ciba