After I was asked again today how to properly patch a rubygems package, here is a quick how to.

First things first we branch the package.

darix@tengu ~/osc/tmp % osc bco devel:languages:ruby:extensions/rubygem-net-ssh-session
A    home:darix:branches:devel:languages:ruby:extensions
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session/net-ssh-session-0.1.6.gem
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session/rubygem-net-ssh-session.changes
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session/rubygem-net-ssh-session.spec
At revision 9edd872bc9121e1c68a71d057dfa607f.
Note: You can use "osc delete" or "osc submitpac" when done.

darix@tengu ~/osc/tmp % cd home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session

So far nothing unexpected a gem file and spec+changes.

x11vnc allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.

• log in to your target machine via ssh
• call "x11vnc -storepasswd" (attention: this will store the password in ~/.vnc/passwd)
• log out and from your "viewer machine" call "x11vnc_ssh username@targethost"

if vncviewer :$port $3; then break; fi

Something I wanted to share is a device I recently built. It is a complete net player for music files, served by a NAS. It’s now finished and “in production” now, so here is my report. [caption id=“attachment_616” align=“alignleft” width=“595”] The cherry ear net player, based on raspberry pi and HifiBerry Amp+.[/caption]

Hardware

The device is based on a Raspberry Model B+ with a HifiBerry Amp+. [caption id=“attachment_618” align=“alignleft” width=“446”] Cherry Ear backside with connectors and power supply[/caption]The Amp+ is a high-quality power amplifier that is mounted on the Raspberry mini computer, shortcutting the sub optimal audio system of the raspy. Only loudspeakers need to be connected, and this little combination is a very capable stereo audio system.

Software: Volumio

On the Raspberry runs a specialised linux distribution with a web based audio player for audio files and web radio. The name of this project is Volumio and it is one of my most favorite projects currently. What I like with it is that it is only a music player, and not a project that tries to manage all kind of media. Volumios user interface is accessible via web browser, and it is very user friendly, modern, pretty and clean.

It works on all size factors (from mobile phone to desktop) and is very easy to handle. Its a web interface to mpd which runs on the raspi for the actual music indexing and playing.

[caption id=“attachment_619” align=“alignleft” width=“400”] Volumio User Interface[/caption]The distribution all is running on is an optimized raspbian, with a variety of kernel drivers for audio output devices. Everything is pre configured. Once the volumio image is written to SD-Card, the Raspberry boots up and the device starts to play nicely basically after network and media source was configured through the web interface.

It is impressive how the Volumio project aims for absolute simplicity in use, but also allows to play around with a whole lot of interesting settings. A lot can be, but very little has to be configured.

Bottomline: Volumio is really a interesting project which you wanna try if you’re interested in these things.

The Housing

I built the housing out of cherry tree from the region here. I got it from friends growing cherries, and they gave a few very nice shelfs. It was sliced and planed to 10mm thickness. The dark inlay is teak which I got from 70’s furniture that was found on bulky waste years ago.

After having everything cut, the cherry wood was glued together, with some internal help construction from plywood. After the sanding and polishing, the box was done.

[caption id=“attachment_621” align=“alignright” width=“300”] Sizes [cm][/caption]The Raspberry and Hifiberry are mounted on a little construction attached to the metal back cover, together with the speaker connector. The metal cover is tightend with one screw, and the whole electronics can be taken off the wood box by unscrewing it.

At the bottom of the device there is a switching power supply that provides the energy for the player.

How to Operate?

The player is comletely operated from the web interface. The make all additional knobs and stuff superflous, the user even uses the tablet or notebook to adjust the volume. And since the device is never switched off, it does not even have a power button.

I combined it with Denon SC-M39 speakers. The music files come from a consumer NAS in the home network. The Raspberry is very well powerful enough for the software, and the Hifiberry device is surprisingly powerful and clean. The sound is very nice. Clear and fresh in the mid and heights, but still enough base, which never is annoying blurry or drones.

I am very happy about the result of this little project. Hope you like it :-)

The first part of this little blog series explained the basic operations of chunk file upload as we set it up for discussion. This part goes a bit beyond and talks about an addition to that, called announcing the upload.

With the processing described in the first part of the blog, the upload is done savely and with a clean approach, but it also has some drawbacks.

Most notably the server does not know the target filename of the uploaded file upfront. Also it does not know the final size or mimetype of the target file. That is not a problem in general, but imagine the following situation: A big file should be uploaded, which would exceed the users quota. That would only become an error for the user once all uploads happened, and the final upload directory is going to be moved on the final file name.

To avoid useless file transfers like that or to implement features like a file firewall, it would be good if the server would know these data at start of the upload and stop the upload in case it can not be accepted.

To achieve that, the client creates a file called _meta in /uploads/ before the upload of the chunks starts. The file contains information such as overall size, target file name and other meta information.

The server’s reply to the PUT of the _meta file can be a fail result code and error description to indicate that the upload will not be accepted due to certain server conditions. The client should check the result codes in order to avoid not necessary upload of data volume of which the final MOVE would fail anyway.

This is just a collection of ideas for an improved big file chunking protocol, nothing is decided yet. But now is the time to discuss. We’re looking forward to hearing your input.

The third and last part will describe how this plays into delta sync, which is especially interesting for big files, which are usually chunked.

UnReal World RPG have come long way how it have been distributed digitally since it started on 1992. First it was on multiple BBS as Shareware application and if you ordered then it was delivered by 4 disks by mail and you copied them to your hard disk. It was pure DOS application at that time. Game author Sami Maaranen have been always modern about this kind of things you could send order by email or normal mail on late ’90. After millennium real digital revolution started.

Internet early days

As that Big company released Window 98 and after that Windows XP URW started to look akward as it was still a DOS (it included graphics but still). Distribution model changed from BBS to Internet WWW-page were you could download installation package (still Shareware) and pay for full version by mail.

In this point distributional things started to rise. People wanted to buy a game with credit card and that wasn’t popular way in Finland which caused little bit hustle. Answer for that was start using ‘Albert’s Ambry’ net distribution system. It was working as expected and it had all needed facilities only problem was Albert’s Ambry got out of business rather soon after URW entered to it.

Times goes by and Internet grows

After Albert’s Ambry get out of business years has passed and UnReal World RPG was distributed through it’s web-page. Everything worked just fine until download rate began to be so huge that Internet service provider started to complain about the traffic that URW caused monthly. Time for mirrors and bigger pipes. Paypal arrived and it made credit card payment things simpler.

Distribution models changes 2013 and UnReal World turned away from old-school Shareware system. Shareware is very good model but it’s rather heavy to use. You provide two versions of your application (one that is for testing and another with full whistles and bells or one that can be modelled to full version with password). Shareware was changed to donation based system (and if you want to donate to URW please do so. All money goes to development of the game [Except that food what two cats can eat]). Donation model is easier games like UnReal World which are regularly updated. You get full game straight a head and you donate if you like it.

Modern web days

In same year 2013 URW changed from Shareware to donation based it also was ported to Mac OS X and Linux (openSUSE, Fedora and Ubuntu/Debian supported currently every build). Port was done by me and it was rumble as you try get DOS game to another platform but it was also ported few years back to SDL1 so it wasn’t that bad.

I assume all you gamers know there is one mammoth in modern PC game distribution: Steam. There were also smaller players like: Desura. Their idea is the same. You have distribution system that is standardized (which all games should be working) and you can buy new games to your own catalogue with credit card from their system. URW entered to Desura last year and now Desura is out-of-business. Desura was great channel delivering applications (supported Linux, Mac OS X and Windows) but I understand it’s very difficult to make money when you are wrestling against Steam.

In near future UnReal World RPG will in Steam as it get through Green light program. Hopefully it doesn’t give death kiss to that service too.

Lessons learned

Take time to make your installers as good as you can get. There is no excuse to have awful installer or Tar/RPM/DEB/DMG-package. If anyone can’t play your game straight away they will complain to you or they just move away without taking any second though. That is the power of Steam.

Don’t trust just one distribution model. If your distributor goes out of business have plan B on hand (very near if possible). If you are doing games for Apple iOS then you are out of luck but If you can use multiple ways to distribute your software do it. You need to work little bit more but more places more eyes to stare your application but. Remember these days many youngsters just play what they can download from Steam (and not blaming them from that) or some other shop that is tied to their device. They don’t know how to install game from Internet or they just don’t care.

If you support Linux (as you should). Ubuntu is biggest but also Arch people are fast growing player community (Fedora is non exist and openSUSE is mediocre). Have at least Ubuntu and provide DEB-package (in future Snappy) and if possible TAR-package (If you are willing provide RPM and Arch package). Have menu integration and do you homework with Linux. In future Linux gaming will be on rise if Steam machines take any market share and today you can buy many Linux AAA-games (over 1000) from Steam today!

Sorry to write this but truth is: In many cases user are all wrong (they just can’t understand how to play your game) but they pay the bills so make yourself a favour: fix bugs fast and give support at least at some forum. Community around the game is very hard to build and it even easier to lose. Final wisdom: last support multi platform. Mac OS X and Linux downloads are minority but do you want to cut these customers out?

Ok summer is crazy.. endless and crazy.. Peace out!

The Web Open Font Format (short WOFF; here using Aladin font) is several years old. Still it took some time to get to a point, where WOFF is almost painless to use on the linux desktop. WOFF is based on OpenType style fonts and is in some way similar to the more known True Type Font (.ttf). TTF fonts are widely known and used on the Windows platform. Those feature rich kind of fonts are used for high quality font displaying for the system and local office-and design documents. WOFF aims at closing the gap towards making those features available on the web. With these fonts it becomes possible to show nice looking fonts on paper and web presentations in almost the same way. In order to make WOFF a success, several open source projects joined forces, among them Pango and Qt, and contributed to harfbuzz, a OpenType text shaping engine. Firefox and other web engines can handle WOFF inside SVG web graphics and HTML web documents using harfbuzz. Inkscape uses at least since version 0.91.1 harfbuzz too for text inside SVG web graphics. As Inkscape is able to produce PDF’s, designing for both the web and print world at the same time becomes easier on Linux.

Where to find and get WOFF fonts?
Open Font Library and Google host huge font collections . And there are more out on the web.

How to install WOFF?
For using inside inkscape one needs to install the fonts locally. Just copy the fonts to your personal ~/.fonts/ path and run

fc-cache -f -v

After that procedure the fonts are visible inside a newly started Inkscape.

How to deploy SVG and WOFF on the Web?
Thankfully WOFF in SVG documents is similar to HTML documents. However simply uploading a Inkscape SVG to the web as is will not be enough to show WOFF fonts. While viewing the document locally is fine, Firefox and friends need to find those fonts independent of the localy installed fonts. Right now you need to manually edit your Inkscape SVG to point to the online location of your fonts . For that open the SVG file in a text editor and place a CSS font-face reference right after the <svg> element like:

</svg>
<style type=”text/css”>
@font-face {
font-family: “Aladin”;
src: url(“fonts/Aladin-Regular.woff”) format(“woff”);
}
</style>
…

How to print a Inkscape SVG document containing WOFF?
Just convert to PDF from Inkscape’s file menue. Inkscape takes care for embedding the needed fonts and creates a portable PDF.

In case your prefered software is not yet WOFF ready, try the woff2otf python script for converting to the old TTF format.

Hope this small post gets some of you on the font fun path.