ahoj, tak a tady bude muj web... nekdy
jelikoz, jak se rika, pod svicnem je nejvetsi tma, tak jsem vzdy byl pozadu s udrzovanim vlastniho webu. to se ted ale snazim zmeni a za pomoci wiki kompileru [ikiwiki] se snad podari mit web relativne aktualni a s uzitecnym obsahem
Co se tu vse najde ?
- prvni naznak galerie, neco malo mam i na flickeru a youtube
- muj linkedin profil
- pocatek wiki generovany pomoci desktopwiki zim
- ruzne smeti a drobnosti a napriklad i drobnosti k ruznym linuxovym distrum, ktere mi prosly rukou (debian/ubuntu, mdk/mandriva, suse, slackware, crux, archlinux)
- prehistoricka verze meho webu z roku 2003 a 2004, kdy jsem jeste nepracoval ve firme Et neter a to jedine prave distro linuxu byl Slackware
- par starych screenshotu
- portfolio z doby kdy jsem se venoval webdesignu
[!img http://counter.li.org/cgi-bin/certificate.cgi/197896]
Blog:
arstechnica mela pred nejakou dobou delsi clanek na tema virtualizace, ktery mi jiz dlouho lezel v rss ctecce a cekal az si na nej najdu chvili... tak konecne 
duvody virtualizace
- konsolidace
- migrace(live) pro loadblanacing zateze a chraneni pred vypadkem
- vykonova izolace a bezpecnost
- vyvoj a podpora legacy systemu
ring - bezpecnostni uroven pristupu k hw. bezne procesory ring 0 pro os a ring 1 pro ostatni aplikace. x86 mel vsak jiz drive ring 0,1,2,3, ale 1 a 2 se nevyuzivaly. principem virtualizace je umisteni vmm do privilegovanejsiho ringu a posunuti os vyse. vmm pak muze zachytavat operace a preposilat/emulovat je. u x86 vsak pouziti trap-and-emulate technika nelze vyuzit pred uvedenim podpory virtualizace v x86 procesorech.
virtualizaci provadi VMM - virtual machine monitor. coz je softwareova vrstva pod hostovanymi OS. muze byt nad host OS nebo pod nim. v pripade ze je VMM pod hostitelskym OS tedy mezi nim a hardware, pak se jedna o hypervisor.
virtualizuji se predevsim
- cpu
- hlavni systemova pamet
- storage (napr hadrddisk)
- i/o (napr sitova karta)
hlavni zpusoby virtualizace jsou
- emulace (vcetne binarniho prekladu)
- klasicka virtualizace
- paravirtualizace
emulace - je to co bylo k dispozici pred virtualizacnima moznostma procesru paravirtualizace - zde je nutna modidikace guest systemu aby znal API
podpora virtualizace na x86 - intel-vt a amd-v/iommu
iommu zajistuje automaticka premapovani urcitych struktur a mimojine umoznuje sdileni zarizeni vice virtualnimi stroji. napriklad sitove karty intel podporuji az 8 virtualizovanych pristupu na port.
Posted Sat 06 Mar 2010 08:51:45 PM CETS novym telefonem Nokia E52, ktery mam ted uz skoro pul roku a ktery ma par much (holt nelze dat na neci doporuceni a je vse nutne si overit sam) mi aktualne nezbyva nez zit. Jednou z hodne neprijemnych veci je to, ze tu a tam dojde ke zmene bluetooth kanalu na kterem je DialUP. Obcas je na kanalu 1 obcas na kanalu 5. Duvody mi nejsou zname, jsem rad ze obcasna nemoznost pripojeni me alespon vedla k odhalneni duvodu proc pripojeni obcas selhava.
Dlouhou dobu jsem si vystacil s tim, ze jsem rucne tu a tam upravil /etc/bluetooth/rfcomm.conf. Obe varianty jsem mel jiz pripravene a jen jsem odkomentoval tu aktualne platnou. Vcera jsem si ale jiz ponekolikate rikal, ze toto je hloupe reseni problemu a urcite to pujde resit lepe, automatizovaneji. No a na svete je nasledujici dvojice skriptu, ktere se postaraji o napojeni vzdy. Jako jediny vstupni parametr je bluetooth pojmenovani telefonu, zbytek je jiz dynamicky.
Nyni kdyz se chci pripojit, pustim jen pon.sh a je vystarano, zadne laborovani s configem, dokonce odpada veskera nutnost mit v nem cokoli nakonfigurovano. Jedine zbyva k dokonalosti je osetreni chybovych stavu a mozna nejake klikaci GUI ;o)
/etc/ppp/rfcomm-bind.sh
#!/bin/bash
set -x
DEVICE_NAME="phone2.jhr.cz"
DEVICE_ADDRESS=$(hcitool scan | grep ${DEVICE_NAME} | awk '{print $1}')
DEVICE_CHANNEL=$(sdptool browse ${DEVICE_ADDRESS} | grep -A 10 'Service Name: Dial-Up Networking' | grep 'Channel: ' | awk '{print $2}')
rfcomm bind 0 ${DEVICE_ADDRESS} ${DEVICE_CHANNEL}
/etc/ppp/pon.sh
#!/bin/bash
set -x
/etc/ppp/rfcomm-bind.sh
sleep 3
pon