Viktor Petersson.com
Viktor on Open Source, Scaling, Unix/Linux and Entrepreneurship.
I’m excited to announce that we’ve released a major update to Screenly. As you can see in the screenshot above, we’ve given the user interface a major overhaul. The workflow is significantly more streamlined, and a lot prettier.
You can take the new interface for a spin here. For upgrade instructions, please take a look here.
More information about Screenly is available here.
Ok, this a long rant, but I just need to warn anyone else looking to buy this monitor. It’s the worst piece of garbage I’ve ever owned. If you’re thinking about buy one, just don’t. Pretty much anything else you can get your hands on is better.
tl;dr
On paper, it’s a pretty decent monitor. It’s a regular 23″ monitor with 2x HDMI input and one VGA. It seemed pretty ideal, since I was primarily looking to use it for my Raspberry Pi labs. For me, monitors are pretty disposable, and I don’t pay much attention to them these days.
This monitor however must have been created by a bunch of either extremely incompetent engineers, or skilled engineers with an extreme hate for the human race.
For instance, the input detector is so shitty that when you plug in a regular computer to it, you’ll be way into the operating bootup before it even detects the monitor (if at all). That means, there’s no way in you’ll be able to do access the BIOS with this monitor (unless you know the exact key combinations (and no, it’s not just ‘Delete’ as it used to be in the good old days)). When using this monitor with the Raspberry Pi, things gets way worse.
In order for this piece of garbage to detect the Raspberry Pi, you need to carefully time when you power up the Raspberry Pi compared to the power up cycle for the monitor. If you either power up the Raspberry Pi too early, or too late, it won’t detect it at all and go to sleep.
Then there’s the monitor’s menu system. You’d imagine that a feature like switching between inputs on a monitor with three inputs would be pressing one key. Nope, on the Acer S235HLBII, you need to dive into the menu and dive into a submenu to do this. Moreover, you can’t even get to the menu if the monitor can’t detect any input.
If you could at least force the monitor to a given input, I guess I could live with this monitor, but you can’t. It will automatically jump back and fort in order to its own pathetic probing.
For the above reasons, I want to congratulate Acer for designing the world’s shittiest monitor.
Since we started WireLoad, the number of websites we host have grown steadily. It’s a myriad of sites, ranging from product sites to websites belonging to friends and family. Many of them are WordPress-sites (just like this one), while others are more complicated. Some use databases, while others don’t. Since we’re often in a rush when we set up a site, documentation often suffers, and you have to spend time later on trying to decipher how things were set up.
This past week I finally had enough and decided to resolve this issue once and for all. What we really needed was a template-based system that could take care of everything and provide us with a user friendly interface. Puppet felt like the best tool for the job so I got busy writing a custom module for this.
The final result is a module I named Puppet-hosting. It allows you to manage all your websites using Puppet. To add a new site, all you need to do is to add a few lines to in your site.pp, and you’re all set.
Here’s an example of how it can look:
hosting::site { 'My Website': type => 'wordpress', url => 'mysite.net', url_aliases => ['mysite.*', 'www.mysite.net'], ip => $ipaddress_eth0, contact => 'Viktor Petersson <[email protected]>', } |
Not only does this make it much easier to manage all the sites, it also speeds things up and avoids human errors, such as typos (and if you do have a typo, it’s easy to spot, since it’s only a few lines in sites.pp).
I’m astonished by the amount of traction we’ve been seeing for Screenly. The Open Source-version is growing rapidly in traction, while the wait-list for the Pro-version is growing.
Given the amount of traction, we’ve now allocated more resources from WireLoad towards Screenly. The first priority right now is a cleanup of the code base and to improve the user interface for Screenly OSE.
Since I’ve been receiving a lot of emails from the contact form on my website about Screenly, we felt that it was important to push out a website for Screenly. We’ve now done this, and you can find it at ScreenlyApp.com. On the website, you’ll find more information about Screenly, along with a live-demo of Screenly OSE.
There’s no doubt that virtualization and the cloud is here to stay. So you migrated your entire architecture to the cloud and everyone is happy. Eventually, you’ll come to a point where you start decommission servers.
If this was an on-premise server, all you had to do was to powered it off and perhaps put it to use elsewhere (or if virtualized, simply delete it). In the cloud however, it’s tempting to do the same.
What people don’t think about however is that most cloud vendors use regular magnetic disks. This means that when you delete a virtual drive, it will be provisioned to someone else. Normally, the first thing the next person who gets provisioned your old disk blocks (or parts of it) would do is to format it and fill it with data.
However, if this person is a malicious user, s/he could restore what was written to those disk blocks, just as s/he could with a magnetic drive that has been formatted.
Therefore, before I decommission any drives in the cloud, this is what I do:
- Power off the system
- Change the boot device to a Live CD (most linux-distributions will do)
- Run shred on the device
- Power off the system and delete the drive
While shredding the drive will take a fair amount of time, we know that even if a malicious user is provisioned the same disk blocks, they won’t find any of your data.
I’m a long-time fan of Axis’ IP cameras. I’ve played with a few other IP cameras too, but I’ve never come across a camera with the performance and stability of Axis’ products.
Recently I deployed two Axis M1114-cameras. It’s an impressive device with built in motion sensor (that can record to a SMB or FTP) with Power over Ethernet (PoE). The optics in the device is equally impressive, as it capable of recording data in down to 0.6 Lux.
Once I had deployed the cameras, I wanted to view the feeds on two statically mounted monitor. With the help of two spare monotors and an Asus EEEPC (a low-powered Atom-based computer with both HDMI and VGA output) I was able to do just that. A simple Ubuntu installation with auto-login did the trick. The secret sauce however was mplayer.
Since this is a low-powered computer with a rather powerful GPU (Nvidia ION), I had to offload the rendering to the GPU to avoid overheating. After installing the required GPU drivers and configure both monitors, all I had to do was to create two scripts and have them launch at boot:
cam0.sh
#!/bin/bash sleep 5 while [ true ] do mplayer -nosound -display :0 -quiet -vo vdpau -vc ffh264vdpau -fs rtsp://cam0/axis-media/media.amp?videocodec=h264 -rtsp-stream-over-tcp -hardframedrop sleep 2 done |
cam1.sh
#!/bin/bash sleep 5 while [ true ] do mplayer -nosound -display :0.1 -quiet -vo vdpau -vc ffh264vdpau -fs rtsp://cam1/axis-media/media.amp?videocodec=h264 -rtsp-stream-over-tcp -hardframedrop sleep 2 done |
Simple as pie! Even with two streams, the computer is at 99% idle. Also, even if the power goes out, the computer will automatically boot up and show the stream.
If you have different hardware, you might need to adjust the ‘-vo’ and ‘-vc’ variables to fit your hardware.
Rack-servers make your life easier. They allow you to stack a bunch of servers into a small area while still keeping them well organized. Unfortunately, most server-vendors know this, and will charge you an arm and a leg for them. I recently had to build up a small virtualization-farm, and I really wanted to keep all server in a rack without having to spend a fortune on servers.
Enter HP ProLiant DL-120. It might not look too impressive, but for the price-point (I paid ~$800 each), it’s not bad 1U server. However, we haven’t started with beefing it up.
Yesterday I delivered a speech at the gSocial. If you haven’t heard of gSocial, it is the largest independent event for the Google Apps Channel Community. My talk was about email migration, and what we have learned since launching YippieMove back in 2008.
A while ago I started hacking on Screenly, a digital signage solution for the Raspberry Pi. It has been a huge success with a lot of traction from the Raspberry Pi community.
The open source edition of Screenly (a.k.a. Screenly OSE) is an excellent tool if you want to setup a single sign. All you need is a Raspberry Pi ($35), some cables, and a monitor. You can literally be up and running in five minutes (not including the time it takes to flash Rasbian to the SD-card).
But what if you want to manage a number of nodes? Let’s say you have one hundred nodes that you want to manage from place? The answer to that is Screenly Pro. It’s based on the same platform as Screenly OSE, but it enables you to easily manage a large number of nodes. It also comes with a number of other improvements to make it easier to setup.
We already have a fully working beta of Screenly Pro running, but we are now taking ready to start letting new users in. If you’re interested, please sign up for the wait-list and we’ll let you know as soon as we’re ready to ship.
gSocial is a conference for Google Apps resellers and ISVs. I attended the event last year, and I was really impressed. I’m back for the conference this year, but I will aslo be giving a talk.
My talk will be on the topic of email migration and what we’ve learned over the years working with YippieMove.
The event also happens to have great timing, since we are just about to release YippieMove’s API, and we’d love talk with the bright people at gSocial about it.
The schedule for the event is available here, and you can register here.