Los episodios están disponibles en streaming (nada de descargas, aunque seguro que alguien se curra la forma de bajárselos) ;D y tienen algo de publicidad al principio y por en medio. La calidad es bastante buena, aunque tampoco hace falta mucho para ver a Cartman. Y lo más importante es que parece que no están restringidos por IP/país, al menos a mi ahora mismo me funciona. :D A ver si otras cadenas/productoras toman ejemplo…
Ayer publicaba soitu.es un profético artículo de Juan Varela titulado La jornada de reflexión ya no existe, sobre el sinsentido que es hoy en día la jornada de reflexión del día antes de las elecciones, así como la prohibición de publicar encuestas durante toda la semana anterior. El artículo se centraba sobre todo en el hecho de que, aunque por los medios de comunicación “clásicos” (¿síncronos?) no nos bombardeen con propaganda electoral y datos de sondeos, cualquiera puede ir a Internet (asíncrono) y acceder a los datos de días anteriores (bueno, hemerotecas de papel también había antes, ¿no?), y leer opiniones y discusiones en blogs y foros que nadie puede regular.
Está claro que las leyes tienen que reflejar la realidad de la sociedad que regulan, y en este caso como en muchos otros, se están quedando desfasadas y no tienen ningún sentido.
Street View es una de las funcionalidades más cañeras de Google Maps: permite moverse “a pie de calle” en *casi* 3D por unas cuantas ciudades de EEUU con imágenes reales de 360º, pudiendo avanzar por una calle, girar en una esquina, mirar hacia los lados, etc.
The drivers that Ubuntu installs by default were giving me lots of headaches depending on the network’s access point: on some of them the card worked OK; on some others I kept loosing the connection every few minutes, or I couldn’t connect at all. I never found out if the problem was the encryption algorithm in use, or the wifi a/b/g/whatever protocol. Bottom line is the driver worked on some networks but didn’t on some others.
A co-worker told me he had the same problem until he switched to the ndiswrapper driver, so reluctantly I tried it. It work great. :)
More info here:
En los tiempos que corren, lo normal es pensar que la mayoría de las comunicaciones electrónicas entre distintos continentes se realizan vía satélite. Pues no, muchas de éstas comunicaciones van por cables de fibra óptica bajo los océanos.
De vez en cuando se producen accidentes: se corta algún cable porque lo arrastra una red de pesca o se engancha con el ancla de un barco, y deja incomunicado a parte de un país o varios países durante unos días hasta que se establecen rutas alternativas o se repara el cable. Otras veces no es tan grave y ya había varias rutas hacia esa zona, y lo único que pasa es que el ancho de banda con la zona se ve reducido drásticamente. Las roturas “a gran escala” que lleguen a incomunicar o mermar las comunicaciones de toda una zona no pasan muy a menudo, tal vez 2 ó 3 veces al año, y es curioso porque (batallita del abuelo mode ON) en mi anterior trabajo, donde administraba el servidor de correo electrónico corporativo de la compañía, se notaba perfectamente cuando se rompía un cable que conectara a Asia porque disminuía considerablemente la cantidad de SPAM que llegaba al servidor (batallita del abuelo mode OFF). XD
¿Y a qué viene todo éste rollo? Pues a que estos días en cuestión de poco más de una semana se han roto CINCO cables y todos en la misma zona: Iran, Irak, Golfo Pérsico…
Y las interpretaciones… bueno, pegadle un vistazo a los comentarios en cualquiera de esas páginas. Lo que parece estar claro es que la rotura de un cable es algo normal; la de dos, en la misma zona, al cabo de un par de días… mucha casualidad; pero ¿CINCO? Y más en una zona conflictiva como Oriente Medio. Algo pasa.
Pero, ¿qué? Las explicaciones conspiranoicas parecen apuntar a dos posibles culpables:
EEUU: En las últimas guerras, la información más veraz e inmediata ha llegado de primera mano por parte de bloggers en las zonas en conflicto. Ya no es como la primera Guerra del Golfo, que las noticias nos llegaban por los canales “oficiales” que nos enseñaban lo que querían que viéramos, las asépticas imágenes verdosas de los intensificadores de luz que mostraban los telediarios a la hora de la cena como si de una película se tratara, y no nos hemos enterado de muchas cosas hasta varios años después. Incomunicar toda una zona podría ser el primer paso de cara a una operación militar a gran escala evitando que ciertos detalles lleguen a la opinión pública por medios “sin adulterar”.
Alguno de los propios países incomunicados: varios regímenes asiáticos y de Oriente Medio ponen todos los medios a su alcance para censurar según qué páginas, foros o chats de Internet y mantener a sus habitantes libres de “influencias” occidentales, pero de una forma u otra al final la gente consigue saltarse estos bloqueos. Ahora bien, si directamente no hay Internet…
¿O es algo completamente normal y lo que pasa es que cada vez hay más gente con demasiado tiempo libre conectada a Internet y con ganas de buscarle los tres pies al gato? ;D El tiempo lo dirá.
One detail about VPNs that I’ve learnt this week the hard way:
If you want to use a VPN as your default gateway and not only to reach some private networks, you have to add first a static route to reach the VPN server through your current gateway.
It may not be very obvious but it’s quite logical: in order to start and maintain the VPN, you need to have network connectivity with the VPN server, that isn’t on our local network, so we reach it through our default gateway (the DSL router or whatever). Once the VPN is up, the “in transit” VPN is just TCP, UDP or some other protocol packets flowing from your host, through your gateway, and reaching the VPN server, that “unpacks” the actual VPN traffic. And what happens if now we set a default gateway on the other side of the VPN connection? It “overwrites” the previous GW, the DSL router. The new GW is not on our real local network anymore, we can’t reach it, so our “in transit” VPN packets can’t get to the VPN server.
Think about it. It’s quite silly, but it’s one of those things that get set up for you when configuring a VPN using a GUI, and you don’t even realize about them until you have to deal with things at a lower level (configuring a router, dealing with a server config files, etc.)
No me voy a extender demasiado porque suscribo punto por punto todo lo que comenta Enrique: siempre me han parecido una bobada, nadie puede obligarme a nada sólo por el hecho de leer un texto que, además, viene después de la información sobre la que pretende imponerme esas obligaciones. Es de locos. Pero todos hemos visto cómo después de que algún “jefecillo espabilao” se lo pusiera en la empresa, ha habido más de tres y cuatro borregos que han hecho copy-paste en su firma para parecer más… ¿más? Y copiando unos de otros, al final media empresa con el disclaimer dichoso sin saber muy bien cómo ni por qué, pero ¡mola!. Una moda más, y como todas las modas, “sin chicha ni limoná”.
Aparte de al borreguismo, lo achaco a que todavía hay mucha gente que no está preparada (por así decirlo) para las nuevas tecnologías, y a alguna mente pensante (igual de poco apta con éstas cosas) se le ocurrió la genial idea de éstos textos para lavarse las manos ante las inevitables meteduras de pata propias y agenas.
Lo que está claro es que si el mensaje llega, llega a su destinatario. Por definición. El que pone en el “To:”. Ni el MUA ni el MTA van a meter la pata, si hay error será humano y en el lado del remitente “de gatillo fácil”.
Los problemas que veo son:
Fe ciega en el auto-completado del Outlook. Ah, ¿que se lo he mandado al que no toca? Pues no es culpa mía, es del Outlook (vale, nos ha pasado a todos alguna que otra vez, quien esté libre de pecado que tire la primera piedra…)
Falta de profesionalidad unida a lo fácil que es darle al botón de “Forward”. Porque claro, si leyendo un documento confidencial que tengo en papel se me ocurre una broma graciosísima, lo que no hago es fotocopiarlo y mandar copias a 10 amigos para ponerlos en contexto y contarles la gracia. Sin embargo con el correo electrónico…
Falta de concienciación en el uso de herramientas de cifrado de información. Pero en fin, si más de una vez he sudado sangre para intentar explicarle los fundamentos del cifrado de clave pública a algún Ingeniero en Informática, no quiero imaginarme lo que puede ser intentar que lo use sin meter la pata (¡y sin auto-completado!) una persona que no está acostumbrada a éstas cosas…
En fin, que si, que éstas cláusulas se ponen porque existe un problema, eso no lo niego. Pero no son la solución, no aportan nada, sólo más confusión.
Y menos mal que había dicho que no me iba a enrollar… XD
WordPress MU 1.3.2 has been released. It gets the project in sync with WordPress 2.3.2 and besides that adds several WPMU-specific security fixes, so it’s a must.
The full package is available for download here. If you already have the previous release installed (simply 1.3, but it was in sync with WP 2.3.1) you can use the following patch to upgrade it more easily: wpmu-1_3-1_3_2.diff
It has happened to me a cuple of times when dealing with UDP-based services that, when a server has more than one network interface (either physical or virtual), all the UDP traffic goes out through the interface on the default gateway’s network segment and with that interface’s IP address, even when the original request came through the other interface and was directed to the other IP address.
Graphically, say you have something similar to this:
If the server receives a request on IPa, the response goes out through that same interface and with origin IPa. But if the request arrives on IPb through the interface on the right, the response is also sent through the left interface with IPa. And what happens when the client receives a response from an incorrect IP address? Maybe even from a completely different network segment? And if there’s a fw in between doing NAT?
Of course this breaks the service. This week I’ve had this very problem setting up a L2TP VPN, and it was impossible to establish the tunnel. On some other ocasions I’ve had a similar problem with a DNS server, and the outcome depended on the client’s operating system: some OSes accepted the DNS response even when it came from a different address than that of the server originally queried; others would reject it and even raise a security alert.
I guess that this behaviour can be programmatically controlled. I mean, when you receive a packet you can check the IP address it was sent to, and craft the response so that it gets sent with that same address from the right interface. But it seems that this is seldom done.
Yesterday I got around this issue with the help of iptables and a coworker more knowledgeable than me on routing issues:
with iptables, you can detect the traffic to “redirect” and mark it
depending on this mark and using “ip rule/route”, have a special routing table that sends this traffic to the proper GW/through the right interface.
with iptables again and using the previous mark, do a SNAT on the origin IP address
An example for redirecting all UDP traffic from a certain $PORT using IP address $IPb through gateway $GWb would be:
echo 255 local > /etc/iproute2/rt_tables
echo 254 main >> /etc/iproute2/rt_tables
echo 253 default >> /etc/iproute2/rt_tables
echo 0 unspec >> /etc/iproute2/rt_tables
echo 200 udp >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table udp
ip route add default via $GWb dev eth0 table l2tp
iptables -t mangle -A OUTPUT -p udp -m udp –sport $PORT -j MARK –set-mark 0×1
iptables -t nat -A POSTROUTING -m mark –mark 0×1 -j SNAT –to-source $IPb
Últimos comentarios
RSS