Aug 30 2010

wiki: Notes sobre entorns de programació

0 comments - Post a comment |

En un .txt tenia unes notes que havia pres sobre entorns de programació, escencialment la conferència de la que són les notes parlava sobre PHP i diferents formens de fer el desplegament dels projectes. Aquesta informació l’he passat a una pàgina del wiki amb la idea d’anar-la actualitzant per altres llenguatges especialment amb la idea de afegir-hi notes de python.

Així doncs l’enllaç del wiki és a: Notes about programming environments and deployment. Tal com podeu deduir amb el títol les notes són amb anglès, sento no recordar la conferència per afegir-hi la presentació.

A continuació enganxo el contingut de la wiki de forma dinàmica, així quan actualitzi la wiki s’actualitzarà l’article:

Notes about programming environments and deployment

Environments:

  • Staging: test your deployment process/scripting (not your code)
    • no developers access, unless they are also sysadmins
    • very restricted outbound networking
    • mirrors production as best as possible
  • Pre-production (optional): test the code in prod env wo/impacting customers
    • test app w/prod setting wo/customer interaction
  • Production: real live environment
    • developers not have access (they can be tempted to fix something)
    • deployment should be done wo/developer input
    • very limited inbound traffic, generally only the service that being served

PHP

Deployment options:

  • rsync
  • source control
  • PEAR
  • os-based

Which should you use?

  • something simple: rsync
  • multiple dispare platforms: pear
  • internal w/minimal dev input: os-based (like. yum/apt)

References:

Aug 23 2010

Entenent els frames I, P i B

0 comments - Post a comment |

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:

  • I-Frame: també anomenat keyframe. No té cap frame de referència i pot ser decodificat per si mateix. Podem pensar que és algo semblant a un JPEG.
  • P-Frame: El contingut del mateix és dedueix d’un frame previ de tipus I o P, és impossible decodificar-lo sense mirar aquesta referència.
  • B-Frame: per decodificar-los cal mirar els frames anteriors i següents de tipus I i P.

Aquest últim tipus de frames són interessant per dues raons:

  • Són fàcils de predir
  • No impacten en la qualitat dels frames següents

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.

  • PTS Presentation Time Stamp: també podem entendre’l com una forma de saber el número de frame, ordre en que es poden veure els frames decodificats.
  • DTS Decoder Time Stamp: ordre en que es processen els frames per ser decodificats.

Un exemple, per entendre-ho millor:

  • Suposem que això és un petit video: I-0 B-1 B-2 P-3
  • L’ordre DTS seria: I-0 P-3 B-1 B-2

Per tal de simplificar les coses el video s’enmagatzema en l’ordre DTS.

El problema

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.

DIVX (i Xvid)

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.

Aug 21 2010

Què és un WebHook?

0 comments - Post a comment |

WebHook logo
Un WebHook és una HTTP callback, o sigui, un HTTP POST que es dona quan algo passa (un event); o sigui, que podem definir WebHook com a sistema de notificació d’events per HTTP POST.

El valor més important dels WebHooks és la possibilitat de poder rebre events quan aquest passen no a través dels ineficaços mecanismes de polling.

Si voleu més informació sobre aquest tema: WebHooks site.

Aug 20 2010

wiki: Glossari de seguretat

0 comments - Post a comment |

Al meu wiki he començat a construir un glossari sobre seguretat, com sempre relacionat amb linux. Bàsicament són petits resums, sovint en anglès, sobre com funcionen certs protocols, mecanismes, estàndards, llibreries, software, etc.

L’enllaç original del contingut és: Gloassari de seguretat

A continuació incrusto de forma dinàmica la pàgina del wiki, perquè s’actualitzi l’article en temps real. Potser això no serà visible des de l’RSS, ho desconec. Per tant, aquesta pàgina estarà en construcció indefinidament, ja que l’usaré com a quadern de notes per aquests temes. De la definició de certs termes se’n poden derivar, podcasts, screencasts, articles, etc.

Glossari

  • Public-key cryptography is a cryptographic approach which involves the use of asymmetric key algorithms instead of or in addition to symmetric key algorithms.
  • Asymmetric key algorithms are used to create a mathematically related key pair: a secret private key and a published public key.
  • public key fingerprint: is a short sequence of bytes used to authenticate or look up a longer public key. Fingerprints are created by applying a cryptographic hash function to a public key. Since fingerprints are shorter than the keys they refer to, they can be used to simplify certain key management tasks.

Public-key cryptography, how it works: Wikipedia

  • Authenticity: we can create a digital signature of a message with private key and it can be validated with public key.
  • Confidentiality and Integrity: encrypt message using public key, only can be uncrypted with private key.
  • Creating pub and private key: An unpredictable (typically a large randomly chosen) number is used to begin generation of an acceptable pair of keys suitable for use by an asymmetric key algorithm.

  • Example of encryption:In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. Security depends on the secrecy of that private key.

  • Example of signature: In some related signature schemes, the private key is used to sign a message; but anyone can check the signature using the public key. Validity depends on private key security.

  • Diffie-Hellman fundamentals:In the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key. After obtaining an authentic copy of each other's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used as the key for a symmetric cipher.

My own schemas:

  • encrypt a document: send a document encrypted using your private key but it can be decrypted with your public key, this is a guarantee for athenthicity, only you can do a document that can be decrypted with your public key



  • sign package: with private key can sign a package, then when anybody has package using the public key can verify that is a trust package


  • sign raw data: the process and result is the same, when sign a package


  • secure mail:
    • for sign and crypt a raw email, the procedure is create a hash signature of raw data, then signature is encrypted with private key finally raw data + signature are encrypted with public key of the recipient.
    • when recipient recieves secure mail, using private key decrypts de package and gets raw email + mail signature. Now recipient can read email but after decrypting signature with public key of sender obtains mail hash signature after validating the signature recipient knows authenticity of mail.


  • ssl_basics and diffie hellman: using priv key #1 and pub key #2 can get a key, and using priv key #2 and pub key #1 can get the same key. This shared key is not exchanged over the network and only user #1 and #2 can get it, then they use the key for a symetric cypher mechanism because it needs less resources than use pub-key mechanisms to encrypt packets. Cypher mechanisms used by SSL typecaly are: AES, DES, 3DES, Blowfish, RC4, etc.


  • PKI:
  • PGP uses web of trust instead of PKI
  • SSL v2 and v3. The Secure Sockets Layer (SSL) protocol allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection.
  • TLS v1 (RFC 2246). The Transport Layer Security (TLS) protocol from the IETF will eventually supersede SSL while remaining backward-compatible with SSL implementations.
  • PKCS #1. RSA standard that governs implementation of public-key cryptography based on the RSA algorithm.
  • PKCS #3. RSA standard that governs implementation of Diffie-Hellman key agreement.
  • PKCS #5. RSA standard that governs password-based cryptography, for example to encrypt private keys for storage.
  • PKCS #7. RSA standard that governs the application of cryptography to data, for example digital signatures and digital envelopes.
  • PKCS #8. RSA standard that governs the storage and encryption of private keys.
  • PKCS #9. RSA standard that governs selected attribute types, including those used with PKCS #7, PKCS #8, and PKCS #10.
  • PKCS #10. RSA standard that governs the syntax for certificate requests.
  • PKCS #11. RSA standard that governs communication with cryptographic tokens (such as hardware accelerators and smart cards) and permits application independence from specific algorithms and implementations.
  • PKCS #12. RSA standard that governs the format used to store or transport private keys, certificates, and other secret material.
  • S/MIME (RFC 2311 and RFC 2633). IETF message specification (based on the popular Internet MIME standard) that provides a consistent way to send and receive signed and encrypted MIME data.
  • X.509 v3. ITU standard that governs the format of certificates used for authentication in public-key cryptography.
  • OCSP (RFC 2560). The Online Certificate Status Protocol (OCSP) governs real-time confirmation of certificate validity.
  • PKIX Certificate and CRL Profile (RFC 3280). The first part of the four-part standard under development by the Public-Key Infrastructure (X.509) working group of the IETF (known at PKIX) for a public-key infrastructure for the Internet.
  • RSA, DSA, ECDSA, Diffie-Hellman, EC Diffie-Hellman, AES, Triple DES, DES, RC2, RC4, SHA-1, SHA-256, SHA-384, SHA-512, MD2, MD5, HMAC: Common cryptographic algorithms used in public-key and symmetric-key cryptography.
  • FIPS 186-2 pseudorandom number generator.
  • SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) – is a GSSAPI “pseudo mechanism” that is used to negotiate one of a number of possible real mechanisms.
    • SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports.
    • The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.
    • SPNEGO's most visible use is in Microsoft's “HTTP Negotiate” authentication extension. It was first implemented in Internet Explorer 5.01 and IIS 5.0 and provided single sign-on capability later marketed as Integrated Windows Authentication. The negotiable sub-mechanisms included NTLM and Kerberos, both used in Active Directory.
    • RFC 4178
  • SASL (Simple Authentication and Security Layer) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL.
    • Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another.
    • They can also provide a data security layer offering data integrity and data confidentiality services.
    • DIGEST-MD5 provides an example of mechanisms which can provide a data-security layer.
    • Application protocols that support SASL typically also support Transport Layer Security (TLS) to complement the services offered by SASL.
    • SASL mechanisms
      • “EXTERNAL”, where authentication is implicit in the context (e.g., for protocols already using IPsec or TLS)
      • “ANONYMOUS”, for unauthenticated guest access
      • “PLAIN”, a simple cleartext password mechanism. PLAIN obsoleted the LOGIN mechanism.
      • “OTP”, a one-time password mechanism. OTP obsoleted the SKEY Mechanism.
      • “SKEY”, an S/KEY mechanism.
      • “CRAM-MD5”, a simple challenge-response scheme based on HMAC-MD5.
      • “DIGEST-MD5”, HTTP Digest compatible challenge-response scheme based upon MD5. DIGEST-MD5 offers a data security layer.
      • “NTLM”, an NT LAN Manager authentication mechanism
      • “GSSAPI”, for Kerberos V5 authentication via the GSSAPI. GSSAPI offers a data-security layer.
      • GateKeeper (& GateKeeperPassport), a challenge-response mechanism developed by Microsoft for MSN Chat
  • PAM (Pluggable Authentication Modules) – can use kerberos but not support SSO
  • SSH uses PAM, if we want to use SSO with kerberos needs a GSSAPI patch
  • SSSD (System Security Services Daemon ) – It's primary function is to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system.
    • NSS interface
    • PAM interface
    • Offline credentials
    • DBUS service called InfoPIPE
  • DSML Gateway – http://directory.fedoraproject.org/wiki/DSML_Gateway_Design
  • x509 – http://en.wikipedia.org/wiki/X.509
  • RADIUS = AAAA (Autenticación, Autorización, Accounting y Auditing)

Software and libraries for pub-key infraestructure:

  • NSS – Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. For detailed information on standards supported, see Overview of NSS.
  • GSSAPI or GSS-API (Generic Security Services Application) – applications programming interface for programs to access security services. IETF standard.
    • The definitive feature of GSSAPI applications is the exchange of opaque messages (tokens) that hide the implementation detail from the higher level application.
    • The client and server sides of the application are written to convey the tokens given to them by their respective GSSAPI implementations.
    • GSSAPI tokens can usually be sent over an insecure network as the mechanisms provide inherent message security. After some number of tokens have been exchanged, the GSSAPI implementations at both ends inform their local application that a security context has been established.
    • Typical protections guaranteed by GSSAPI are confidentiality and integrity. It's important to mention that authorization is not offered by GSSAPI.
    • In the API there about 45 procedure calls.
    • The GSSAPI allows Kerberos implementations to be API compatible.
    • GSSAPI support SPENGO it's a pseudo mechanism to negotiate new security mechanisms.
    • Known mechanisms: Kerberos, NTLM, DCE, SESAME, SPKM, LIPKEY.
  • SSSD – https://fedorahosted.org/sssd/
  • GOSA – https://oss.gonicus.de/labs/gosa/
  • WebAuth: Kerberos a Apache – http://webauth.stanford.edu/

Greatings

Wikipedia is the most important font of this gloassary. Thanks to everyone who makes it possible.

Aug 18 2010

Album de fotos de Costa Rica

0 comments - Post a comment |

Dijous passat aterrarem a Barcelona després del viatge que hem fet per Costa Rica, així doncs, malgrat ja fa uns dies que treballo he pogut pujar les fotografies del viatge a l’àlbum de fotografies. Com sempre el teniu a:

Les fotografies estan protegies amb password que com sempre els que em coneixeu el sabreu en un moment i els que no, envieu-me un email i ús l’enviaré. Aprofito per recordar que el tinc protegit perquè hi ha algunes fotos que a vegades no és bo que estiguin a l’abast de tothom.

Pel que fa a la web del viatge malgrat ja l’he començat a fer encara li queda força feina per estar acabada, tan aviat com ho tingui ja avisaré. Pels que no voleu entrar a l’àlbum de fotografies i mentre la web no esta acabada podeu anar fent boca amb aquestes quatre notes i imatges que ús deixo a continuació.

Platja privada del parc natural de Manuel Antonio:

Costa Rica > P.N. Manuel Antonio

“Conopy Extrem” a Monteverde:

Costa Rica > Monteverde > Conopy Extrem

Volcà Arenal, foto feta des de l’hotel “Linda Vista del Norte”:

Costa Rica > Arenal > Volcà

Termes “Baldi” a La Fortuna (Arenal) on ens trobarem amb el Joan i la Patri: (esq-drt: Glòria, Torsten, Patri, Joan, Estefania i Oriol)

Costa Rica > Arenal > Termes Baldi

Posta de sol des del jardí de l’hotel Miss Junie a Tortuguero:

Costa Rica > Tortuguero

Caimà dels canals de Tortuguero:

Costa Rica > Tortuguero

Tour en canoa pels canals de Tortuguero amb el senyor Billy, un caçador de jaguars de Nicaragua que amb 84 anys tenia més força per remar que tots quatre junts:

Costa Rica > Tortuguero

Piscines naturals a les platges de Puerto Viejo, on visitarem al Josep Maria i la Carme:

Costa Rica > Puerto Viejo de Talamanca

Esmorzant a la ‘terrassa’ de l’apartament del Josep Maria i la Carme a Puerto Viejo:

Costa Rica > Puerto Viejo de Talamanca

Cocodril d’uns 2′5m que teniem a tocar al dinar del tour del cacao que ens va fer el Sr.Felipe prop de Hone Creek (zona sur Carib de Costa Rica):

Costa Rica > Hone Creek

Dinar al tour del cacao amb la Glòria i el Torsten els nostres companys de viatge:

Costa Rica > Hone Creek

Si en voleu més, ja ho sabeu: album de fotos > viatges > Costa Rica

Jul 31 2010

Avui el blog fa 10 anys!!!

0 comments - Post a comment |

Doncs si tal dia com avui vaig començar a escriure el blog, així doncs, faré una cosa que faig poc sovint i és autofelicitar-me per la constància, si ja sé que no podriem dir que últimament escrigui cada dia però crec que aguantar 10 anys amb certa constància és algo, no?

Bé doncs sempre passa en aquestes ocasions farem una petita llista de bons proposits per aquesta nova etapa de maduresa del blog:

  1. continuar-lo usant com a bloc de notes tècnic
  2. continuar usant-lo per referenciar events de caire més personal o no-professional
  3. començar de forma oficial el ‘screencast‘ sobre el que ja he fet les primeres proves
  4. agrupar aquesta part més multimedia ‘podcast‘ i ‘screencast‘ en una pestanya dedicada per accedir-hi ràpidament
  5. redissenyar-lo completament però aquest cop si tot va bé, fer-ho a través d’una empresa que li doni un bon acabat
  6. re-editar els posts antics perquè adquireixin formats més unificats, suport de tags, centrat i mida d’imtges, repassar enllaços trencats, etc.
  7. més protagonisme als posts antics (this week last years)
  8. integrar uwish
  9. integrar lifestream a la pantalla principal en forma d’stick item a més de sindicar més feeds en aquesta llista: twitter, my shared items del google reader, etc.
  10. seguir fent del blog algo que m’enganxa i que trobo a faltar quan no faig

També vull fer un comentari sobre la línia que té el blog aquests últims anys, en que el nombre de posts ha baixat força però la qualitat i densitat tècnica han augmentat molt. Malgrat això em fa baixar en nombre de lectors és més fidel a la meva persona i el converteix en una eina encara més útil per mi.

Finalment hi ha una llista d’articles pendents de publicar que conte coses com:

  • iPython
  • ESI – Edge Side Includes
  • LVM
  • SSTP
  • SVG amb long polling
  • array vs CouchDB
  • scribe
  • DNSCurve
  • Google Talk chatback badge
  • MyProxy – credential management service
  • SSL i TLS a fons
  • Desktop notify system with python
  • oProfile
  • etc

Però sobretot el que estic impassient per començar a document en forma de post, d’screencast i del que faci falta és el tema del AMQP, porto mesos treballant amb un borrador que cada cop és més extens i que de ben segur hauré de dividir en diversos trossos perquè les seves dimensions ja fan por, però realment estic disfrutant com mai amb aquest tema.

Doncs res, agraïr-vos també a tots els que em llegiu que ho continueu fent malgrat el pesat que em faig en alguns moments. Demanar-vos que no tingueu por en presentar-vos perquè a les jornades tècniques on em deixo caure acostumo a trobar gent que ha passat pel meu blog alguna vegada i això sempre fa moltíssima il·lusió.

Bé doncs gràcies a tots i ens veiem quan torni de Costa Rica, on estic passant les meves vacances en aquests moments.

Jul 27 2010

Podcast 2×06: Com funciona Kerberos? autenticació i autorització (AA)

0 comments - Post a comment |

El podcast



 Podcast 2x06: Kerberos [27:18m]: Play Now | Play in Popup | Download (179)

Notes

Estàndard RFC1510 per l’autenticació, destaquen les funcionalitats de:

  • autenticació mutua
  • temps de connexió ràpids (session tickets)
  • delegació (autenticació recursiva entre serveis)

Esquemes

Simplifiació del funcionament

Hi ha 6 tipus de missatges (5 obligatoris + 1 opcional), agrupats en 3 su-protocols:

  • AS (Authentication Service) – es produeix durant el procés de “login” i li permet al client poder demanar un ticket per accedir als recursos (TGT)
    • KRB_AS_REP
      • Client principal name.
      • Timestamp.
      • Kerberos target principle name (realm).
      • Requested lifetime.
    • KRB_AS_REP
      • La primera part va xifrada usant la clau d’usuari, conté:
        • User-TGS key (generated by the KDC).
        • Kerberos target principle name (realm).
        • Ticket lifetime.
      • La segona part és el TGT, va xifrat usant la clau TGS generada pel KDC només els servidor la poden obrir, malgrat això s’enmagatzema en el client i conté:
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
        • Client IP address (taken from the initial KRB_AS_REQ).
  • TGS (Ticket Granting Service) – a través del TGT el client poy demanar un “service ticket” (ST) necessari per poder accedir a un servei. El TGT té un funcionament semblant al d’un password (expira amb el temps i no requereix password), el ST obtingut seria semblant a un visat d’accés a un país.
    • KRB_TGS_REQ
      • Service principal name.
      • Requested lifetime.
      • TGT (still encrypted with the TGS key).
      • Authenticator (encrypted with the user-TGS key and containing a client timestamp) – The authenticator guarantees that the request originated from the client.
    • KRB_TGS_REP
      • La primera part va xifrada amb la clau TGS de l’usuari (el KDC l’extreu del TGT) i conté:
        • Service principal name.
        • Ticket lifetime.
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
      • Part dos, és el “service ticket” (ST). Xifrat usant la clau del servei TGS. Conté:
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • Client IP address.
  • Client/Server (AP) Exchange – per accedir a un servei el client envia al servei un KRB_AP_REQ amb el ST obtingut. El servei pot o no contestar la petició, a vegades, el servei directament comença la seva sessió.
    • KRB_AP_REQ
      • ST xifrat amb la clau TGS del servei
      • Authenticator – encrypted with the user service key
    • KRB_AP_REP

Característiques

  • ‘Realm‘ es defineix com un domini d’aministració
  • Tots els servidors i participants en les transaccions pertanyen al mateix ‘Realm’
  • Tots els missatges viatgen xifrats usant un codi simètric (no-PKI)
  • La “user key” es genera a partir del “logon password”
  • La “host key” es genera quan el “host” s’uneix al ‘Realm’
  • Si un client vol accedir a un servei i no ha fet el TGS pot enviar el TGT en el “AP exchange” i el servei farà la gestió amb el KDC de forma transparent.
  • Important recordar que:
  • només el KDC pot llegir el TGT
  • només el servei pot llegir el ST

Glossari d’acrònims

  • KDC: Key Distribution Center
  • AS: Authentication Service
  • TGS: Ticket Granting Service
  • SS: Service Server

Referències:

Error coneguts

  • Degut a un error el podcast 2×05 no exiteix. Sento l’error!

Jul 14 2010

Notes sobre Munin i Crontab, problemes amb locales

0 comments - Post a comment |

muninResum de notes interessants que acabo de descobrir sobre: munin, crontab i locales. Tot plegat corrent amb Ubuntu.

  • crontab, té diversos fitxers de configuració a /etc/cron.d la sintaxis d’aquests és la mateixa que /etc/crontab
  • els fitxers que hi ha a /etc/cron.d sovint pertanyen a serveis que necessiten executar ordres periódicament
  • al llençar munin des de dintre d’aquest directori es generaben correus d’error del crontab, queixant-se de problemes amb les locales
  • dins el fitxer /etc/cron.d/munin podem declarar les locales i així no se’ns tornarà a donar el problema
  • si volem sobrecarregar on s’han d’enviar els correu d’error de cron en un dels fitxers que hi ha /etc/cron.d podem declarar la variable MAILTO=user@domain.tld dins el propi fitxer

Jul 13 2010

CouchDB: fixar el límit màxim de revisions per document

0 comments - Post a comment |

couchdb logo
Per defecte i fins que no es fa una compactació de la base de dades CouchDB permet fins a 1000 revisions d’un document, cosa que sovint no acostuma a ser necessari. Així doncs, si volem canviar aquesta paràmetre finalment a la versió 0.11 ja el podem canviar.

Set _revs_limit of a particular database:

curl -X PUT -d "1500" http://localhost:5984/test/_revs_limit
#=> {"ok":true}

Read _revs_limit of a particular database:

curl -X GET http://localhost:5984/test/_revs_limit
#=> 1500

informació original de: accessing database specific options.

Agraiments: gràcies @marcos ;)

Jul 09 2010

Formats gràfics CIF

0 comments - Post a comment |

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 16×16pixels). 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.

  • Membre de:

    penedesfera.cat
    torrelavit.cat
    Add to Technorati Favorites
    Vota'm al TOP CATALÀ!
    Catapings.cat