Reading time: < 1 minute
Tothom sap que una activitat és una acció feta per una persona. Però si hem de disseccionar una activitat podriem fer-ho així:
Reading time: 2 – 2 minutes
Quatre notes que tinc pendents de classificar, com donar suport d’autenticació a postfix de forma ràpida i senzilla.
Paquets que cal tenir a més del postfix: cyrus-sasl, cyrus-sasl-md5.
Línies que cal tenir al /etc/postfix/main.cf:
smtpd_sasl_application_name = smtpd smtpd_sasl_type = cyrus smtpd_sasl_path = sasl2/smtpd.conf smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
Fitxer de configuració del servei d’autenticació /etc/sasl2/smtpd.conf:
pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
Assegurar-se que el propietari del fitxer /etc/sasldb2 és postfix.
El fitxer /etc/sasldb2 és una base de dades Berkeley DB que guarda els usuaris i les seves paraules de pas en text pla. Així doncs, no és molt segur però una solució més que suficient per molts entorns SOHO.
Gestió d’usuaris:
# afegir usuari saslpasswd2 -a smtpd -u domini_exemple.com nom_usuari # borrar usuari saslpasswd2 -d -u domini_exemple.com nom_usuari # llistar usuaris sasldblistusers2
La configuració que heu de posar al MUA pel que fa al servidor de correu ha de ser del tipus:
usuari: nom_usuari@domini_exemple.com pass: el que hagiu definit mecanisme d'autenticació suportats: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
UPDATE 27/2/2012:
Perquè es pugui tenir accés al fitxer /etc/sasldb2 cal que el mòdul smtpd de postfix no es llenci com a chroot. Per evitar això cal modificar el fitxer /etc/postfix/master.cf concretament la línia del dimoni smtpd ha de quedar així:
smtp inet n - n - - smtpd
Per tenir suport de SASL a Ubuntu Lucid cal instal·lar els paquets: sasl2-bin i libsasl2-modules.
Reading time: 1 – 2 minutes
Reading time: 2 – 3 minutes
Aquest estiu m’he comprat un Amazon Kindle de 3a generació després de que fa uns mesos l’Oriol M. em va recomanar comprar-me un llibre electrònic i malgrat les meves reticències vaig parlar amb el Marc M. perquè em deixés el seu Kindle durant una setmana i després de l’experiència vaig llençar-me corrent a comprar-me’n un. Ho vaig fer via ebay i per uns 130€ el vaig tenir a casa en 2 dies. Mai m’hagués imaginat que m’acabaria convertint en un enamorat d’aquest aparell, realment he passat a un altre nivell i llegir llibres amb el eBook s’ha convertit en una experiència molt satisfactoria.
El que més aprecio és:
Reading time: 2 – 2 minutes
Potser a alguns els semblarà rara la recomanació d’una aplicació per Windows i encara més si aquesta esta fet amb Silverlight. Però he de reconeixer que a mi m’esta resultat una eina força còmode.
Perquè l’utilitzo:
Per acabar un parell d’screenshots perquè ús feu una idea del seu aspecte, el primer és la finestra de l’aplicació tal qual la faig correr jo:
el segon és l’aplicació a ‘full-screen’:
Pàgina web de l’aplicació: Seesmic, l’eina esta disponible també com a plug-in d’un munt de navegadors i de quasi tots els sistemes operatius mòbils moderns.
Reading time: 2 – 4 minutes
Quan ens roben el portàtil l’únic que ens queda fer és resar perquè siguem realistes, és molt poc provable que la policia el trobi. Així doncs, el que preten fer prey és enviar-nos tota la informació possible del portàtil després de que ens l’hagin robat.
El seu funcionament és força simple, però al mateix temps s’ha de dir que la idea sembla força eficient. En la versió per linux es tracta d’un script fet amb perl que es col·loca al crontab, de forma que cada x’s minuts es connecta a una URL del servidor de prey o del nostre propi servidor. Aquest URL sovint respon dient que tot va bé, és a dir, que el portàtil no ha estat marcat com a robat. En cas contrari, el servidor respon via HTTP dient que el dispositiu ha estat robat. En aquest moment és quan l’script es posa a treballar i es posa a recollir tot tipus d’informació per reportar-la a la pàgina web:
La compte gratuïta que ofereix la pàgina web permet tracejar fins a 3 dispositius, obviament si usem el nostre propi servidor HTTP podrem tracejar tots els dispositius que volem. Si volem usar més dispositius haurem d’adquirir una compte professional que tampoc sembla massa cara: per exemple, la més econòmica és la de 12€/mes que permet controlar fins a 10 dispositius amb un màxim de 25 informes per cada dispositiu.
Jo he provat la versió de Windows i la de Linux i ambdues m’han funcionat força bé a la primera, però pel que posa a la web també tenen la versió de Mac i la d’Android. Aquest última diria que és molt nova. Malgrat això en els meus dos Androids no uso prey sinó que uso WaveSecure. Pensat especialment per a dispostius mòbils, ja que tenen versions per: Blackberry, Symbian, Windows phone, Java i Android, és clar.
Reading time: 2 – 3 minutes
Tot ordenant .txt he trobat quatre notes que havia fet fa temps extretes de l’experiència i de documents de relacionats amb digital signage que havia anat llegint, per tal de no perdre-les les anoto a continuació:
Entorn:
Audiència:
El missatge:
Tips and tricks:
Reading time: 2 – 4 minutes
Al sentir parlar de formats de video, codecs, DivX, MPEG4, etc. sovint surten a la conversa termes com ara els I-frame, P-frame i B-frame. Cansat de que em soni a xinès he decidit fer-me un petit resum de què és tot plegat, sempre des del punt de vista d’algú que en sap ben poc d’aquests temes.
Podem dividir els ‘frames’ de video en 3 tipus:
Aquest últim tipus de frames són interessant per dues raons:
Degut a que els B-frames depenen del passat i el futur, llavors el decodificador li calen frames I-P del passat i el futur per poder decodificar el frame B. Això ens porta als conceptes PTS/DTS.
Un exemple, per entendre-ho millor:
Per tal de simplificar les coses el video s’enmagatzema en l’ordre DTS.
Arribat en aquest punt podeu imaginar-vos el problema que suposa mostrar un video en ordre, ja que el decodificador ha d’anar composant els frames per mostrar-los am és d’inserir frames on no n’hi han per mostrar el frame que toca.
Aquests famosos codecs per tal de d’atacar aquest problema fan servir un petit truc. La idea seria usar una variant dels frames PB i empaqueten diversos frames en un. Això fa que les aplicacions es pensin que només hi ha un frame i el codec oculta la resta.
Per exemple, si tenim un fitxer que te empaquetat el següent:
In (0 3 1 2) - - - ...
el codec haurà de treure això:
Out 0 1 2 3 ...
El codec posa frames de tipus ‘null’ en el lloc on hi haurien d’haver els frames que no té pel fet de tenir-los empaquetats en un frame. Els codecs ja saben que quan reben un frame null han de descartar-los.
Des del punt de vista del codificador, és important fixar-nos que no s’introdueix un delay corresponent als frames nulls. En un fitxer AVI no hi ha cap relació entre el PTS/DTS guardada enlloc per tal d’informar al decoder quan aquest ha de reproduir.
Reading time: 2 – 3 minutes
CIF (Common Intermediate Format), també conegut com FCIF (Full Common Intermediate Format), és un format usat per estandaritzar les resolucions horitzontals i verticals en pixels de les senyals de video (seqüències YCbCr), aquest nomenclatura es va proposar a l’estàndard H.261.
CIF es va dissenyar per convertir de forma senzilla els estàndards PAL o NTSC. CIF defineix una seqüència de video amb una resolució de 352×288 com PAL, amb un framerate de 30000/1001 (uns 29.97fps) frames com NTSC, amb un codi de color YCbCr 4:2:0.
| SQCIF | 128 × 96 | SubQuarterCIF (subQCIF) |
| QCIF | 176×144 in PAL 176×120 in NTSC |
Quarter CIF, la meitat de la resolució H i V, o sigui, 1/4 de la imatge original |
| SIF(525) NTSC | 352×288 PAL 352×240 NTSC |
Source Input Format |
| CIF/SIF(625) | 352×288 in PAL 352×240 in NTSC |
|
| D1/4SIF(525) | 704×576 (TV PAL) 704×480 (TV NTSC) 720×576 (DVD-Video PAL) 720×480 (DVD-Video NTSC) |
Full size, estàndard NTSC i PAL |
| 2CIF | 704×288 in PAL 704×240 in NTSC |
2 Common Intermediate Format |
| DCIF | 528×384 in PAL 528×320 in NTSC |
Double CIF, té un aspect ratio molt proper al 4:3, millor quailtat que 2CIF i CIF amb el mateix bitrate |
| 4CIF/4SIF(625) | 704×576 in PAL 704×480 in NTSC |
|
| 16CIF | 1408 × 1152 |
Les resolucions xCIF no són quadrades, tenen un ratio de ~1.222:1. O sigui, que una televisió analògica té un ratió de 1.2:1 segons defineix l’estàndard de sistemes de 525 linies (CCIR 601). En les pantalles d’ordinador o de televisió digital es treballa amb blocs de pixels quadrats, o sigui, que les trames xCIF ha de ser re-escalades horitzontalment un ~109% per aconseguir un ratio de 4:3, o sigui, el que equivaldria a 384×288 pixels quadrats.
Les mides d’imatges CIF han estat especialment escollides per ser multiples del que s’anomenen macroblocs (corresponent a 16x16pixels). Per exemple, una imatge CIF de mida 352×288 correspon a 22×18 macroblocs.
Informació extreta de la Wikipedia i de diversos forums dispersos per internet.
Reading time: 2 – 3 minutes
No es tracta d’unes proves de rendiment serioses i estríctes, però almenys en el meu cas m’han servit per tenir una idea del rendiment d’aquestes aplicacions i poder dissenyar diferents arquitectures amb una mica més de coneixement de causa.
Per si no coneixeu les eines:
Sistema sobre el que s’han fet les proves:
Resultats de les proves: