I had an old 22″ monitor standing around, where the integrated CD/DVD player was broken – but lucky me it still had a HDMI input, so… *g
So I stuck the Pi with doublesided super strong mounting tape at the back of it, put some more “sticky points” to hold the wireing in place and that there is no strain on the cables and the Pi – and here you go.
I orginally had it mounted so that the power leads and the SD card are easily accessible from the top,but then realized it would be better when they are on the right side (so that all the cables come out on the left, right and buttom). That super strong mounting tape actually removed some of the original TV’s labels…
Right now I labelled my SD cards, as I am trying different things right now. These are
- XBMC viewing station with OpenElec
- Plain Raspbian for testing software on a plain Linux installation, like Minecraft.
It is great and I am enjoying it – my son as well, as he likes Minecraft and really would like to have this hooked up to his TV… but not yet, not gonna give my toy out of my hands yet.
I just came across Symantec SSL certificates feature cryptography 10k times harder to break than RSA-bit key and Symantec/VeriSign Expands Encryption Options For SSL Digital Certificates.
I must say, I am stunned. AFAIK no certificate has been “broken” yet, and those few ones what have, were implementation errors or via MD5 collision attacks. And then there are plain hack-into-their-system and steal the private keys attacks, like DigiCert. There are a few others most likely.
The problem is not the encryption of the SSL certificate, present SSL encryptions are strong – again, most of them, MD5-based SSL certificate hashes are considered broken (or anything MD5 based in general), and also the recent “Lucky 13” when using a specific cipher.
There are still enough ciphers out there to make existing SSL certs good enough. Deploying a new cipher takes time and is new code, what has not been (security)tested yet.
Attackers will always attack the weakest link, and this is not by bruteforcing the cipher, in most cases they go after the human.
Jacob Appelbaum at the 29C3 keynote about the new, top-secret NSA building in the US and a couple of other things, what gave me the chills – mainly how the US government is – let’s say “performing”.
You can watch it on YouTube.
Or if you want to get the video, the filename is “29c3-5385-en-not_my_department*” on any of 29C3′s mirrors.
Image Credit: NASA (www.nasa.gov), ESA (www.spacetelescope.org), and The Hubble Heritage Team (heritage.stsci.edu)
Some time back I came across Astronomy Picture of the Day – some picture are really stunning. I wanted to have this as a wallpaper, but subtitled with the description (I still want to know what I am looking at!). So I wrote a Bash-script doing that for me.
It requires the following programs
- convert from “imagemagick”
be accessible within $PATH.
All directory references are relative to the directory it is in. It needs two directories “resized” and “subtitled”.
The script doesn’t download already downloaded pictures. When called with no parameter it downloads the latest, or you can also alternatively browse their website and pass the URL to it.
You can download the script here.
By the way, APOD also offers a calendar.
This short post describes a fix for a standby/wakeup problem with XBMC, latest XBMCbuntu (fully updated with Kernel 3.2.0-37-generic-pae and XBMC 2:11.0~git20120423.cd20772-1).
For some reason I couldn’t resume/wakeup from suspend my XBMC system via the remote anymore. In earlier versions you might had something like
echo USB3 > /proc/acpi/wakeup
in your /etc/rc.local. This configured your system tro accept USB-wakup calls via the “USB3″ port. So to get it to work again, the first thing is to comment that line out. Then
root@xbmc:~# dmesg | grep -i flirc
[ 2.014322] input: flirc.tv flirc as /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/input/input2
[ 2.014636] generic-usb 0003:20A0:0001.0001: input,hidraw0: USB HID v1.01 Keyboard [flirc.tv flirc] on usb-0000:00:1d.3-2/input0
If you do a
root@xbmc:~# cat /proc/acpi/wakeup
USB3 S3 *enabled pci:0000:00:1d.3
shows you two things: First, 1d.3 is “USB3″. Then usb5 is what we need in our next step. The new line for /etc/rc.local is as follows:
echo "enabled" > /sys/bus/usb/devices/usb5/power/wakeup
and that needs to go before the “exit 0″ line of course.