Category: Uncategorized

I've been running my ownCloud server on a Raspberry Pi for quite some time now and to say I am enthusiastic about it is rather an understatement. The Raspberry's versatility is incredible and I've recently come across another application that could come in quite handy in the future: Running Asterisk PBX on a RasPi and using it as a GSM Gateway.

Here's a post over at the Carrier-Connect blog that describes such a setup to forward calls over IP for a person's mobile number of country A to the person's mobile number of country B with the help of two Raspberry Pis and two 3G/GSM data sticks that are also circuit switched voice capable. And to make the Asterisk setup as painless as possible there's even ready to go Raspberry Debian (Raspbian) image and documentation available here. Amazing!

From what one reads on the web, OwnCloud seems to have become quite popular. While I have two small Owncloud servers of my own at home I had yet to see someone else use it, too. And to my surprise it happend faster than I thought.

When I recently passed by the desk of one of my co-workers I noticed the familiar ownCloud design in his web browser. It turned out that it was the ownCloud of a company that wanted to share a number of documents with him without using a public storage provider.

Very nice so now I know for a fact now I am not alone. While Dropbox or similar services would have spared the company the effort to set up their own server it looks like privacy and confidentiality were ranked higher than convenience.

How nice!

Here's a link to an interesting post over at Telegeography titled "International bandwidth demand is centralizing". The figure at the top of the post nicely visualizes the two key messages:

Not surprisingly lit (used) capacity of undersea cables continues to increased at a staggering pace, around 50% year over year. Between Europe and the US, for example, capacity of around 12 Tbit/s was added in the past 5 years. Terabits…

The second point of the figure is that unlike in previous years, bandwidth additions have been pretty much equal across the globe and are no longer focused just between Europe and the US. I would have thought differently with the majority of cloud and video streaming services being operated by US companies. But perhaps not so surprising at all with companies such as Akamai making sure content is not streamed across undersea cables but from a server as close to the user as possible.

Remember Delicious? Once upon a time I used Delicious quite a lot to store bookmarks I didn't want to have in the bookmark menu of my web browser and which, in all likelihood, I would never need again anyway. But one never knows and there are pages which are not easily to be found with a search engine and every once in a while I was glad I could go back to my "bookmarks dump".

Then in 2011 Delicious as we knew it faded away and morphed into something different and I had to re-import the bookmarks into my web browser which was an adventure all by itself. This worked quite well for some time but for some reason the bookmark search algorithm in Firefox was really slow and I had to delete the better part of my bookmark pile. But now I'm back in the game again with the ownCloud bookmark application.

After all my posts on ownCloud in the last couple of months you must either have one of your own by now or be weary of my ramblings on it. But I can't help it, I just like it and it proves more and more useful every day for sharing documents as well as calendar and address book synchronization. With a little bookmarklet in the browser I can now save bookmarks again in the cloud with a single click and search through them when needed in ownClouds browser based GUI.

Just like in the good old Delicious days but with privacy added as the data is stored on my server at home. Perfect!

IPv4 addresses are slowly running out. As a consequence a number of ADSL and cable network providers have now started to give customers non-routable private IP addresses and perform Network Address Translation (NAT) at their border gateway to the rest of the Internet. As the NAT is performed on their turf they call it Carrier Grade NAT or CGN.

While being state of the art in wireless networks for many years now CGNs certainly have one advantage, they shield mobile devices from unsolicited packets from the Internet and hence keep power consumption down. Unfortunately there is a major disadvantage as well which is especially troublesome for fixed line connections at home: Your network is not reachable anymore for incoming connection requests.

Many people won't notice but as soon as you are running your own services such as an Owncloud server you are out of luck. Verizon, for example, is switchng to CGNs and private IP addresses and some German cable operators have started doing it as well. While Verizon at least offers a way to opt it seems that others are less flexible. Too bad when you signed a one year contract… I wouldn't be surprised if some will even start asking for extra money for a public IP address. Market economy, scarce resources, you get the idea…

IPv6 is obviously the solution but networks, devices and VPN gateways supporting it are still scarce. Therefore make sure before changing your home network provider that you will really get a public IP address!

The more I use my Owncloud server at home for exchanging files with others and keeping my calender and address book synchronized between various devices without relinquishing control (see here and here), the more I have come to like cloud services. I also use my Owncloud server at home while on the move via HSPA and LTE and when doing so, the major bottleneck is the uplink data rate.

For calendar and address book synchronization and also for downloading files from the cloud, an HSPA connection is fully sufficient. When uploading larger files to the cloud, however, HSPA becomes quite limiting. This is due to the limited uplink speeds of HSPA networks today, typically between 1 and 2 Mbit/s. How times and perceptions change… Not too long ago such speeds were considered amazingly fast. Not that this is an inherently wireless issue as ADSL uplinks are often even slower, most not even exceeding a megabit per second.

LTE is refreshingly different in this regard. When reception is good, I can easily achieve speeds way beyond the 5 Mbit/s my home VPN is limited due to the processing power of my VPN gateway. And for files exceeding just a few megabytes this makes a real difference.

So while for the most part I regard LTE as a capacity extension to server more simultaneous users rather than being there for offering higher download speeds, the uplink speed is the real differentiator for me!

Cloud services seem to be dying at an ever increasing rate these days. A year or two things started for me with Delicious abandoning its popular bookmark service, followed by the announcement of Google to discontinue their RSS reader at some point this year. And now Wetpaint has decided to block the Prepaid Wireless Internet Access Wiki that they hosted on their servers for many years without giving any reasons or warning. Ouch.

Over the years Wetpaint seems to have changed its focus several times and today the hosted Wikis seem to be little more than an unloved project on the side for them. Already over the last year I have noticed that the server the Prepaid Wireless Internet Wiki is hosted on has become slower and slower to the point of being of little use. That should have been a warning sign and an incentive to think about moving the content. But I didn't…

Now the Wiki is blocked and there is no way to export the pages. Support on the Wetpaint Central site for such issues also seems to be zero and all my inquiries have been left unanswered so far. And so once more the lesson is: Never trust a cloud service, your data could be gone in the blink of an eye without any warning.

Too bad, the Wiki has proven to be quite useful over the years.

Here's a question I haven't got an answer for that you might be able to help me with. Who pays whom in the following scenario?:

• A = User
• B = DSL Access Provider
• C = Transit Provider
• D = Video Portal

Obviously the user (A) pays the DSL Access Provider (B) a monthly fee for the DSL line rental

The Video Portal (D) pays the Transit Provider (C) since it sends a lot of data into the network towards the user.

Based on the business model User (A) might pay the Video Portal (D) a fee or the Video Portal is cross-financed in another way, e.g. advertising.

And here's the question: What is the business relationship between the DSL access provider (B) and the Transit Provider (C)? The majority of data exchanged flows from Transit Provider (C) to the DSL access provider (B). Who pays whom at this interface?

Any insight and references are greatly appreciated!

Spring has kept us waiting here in Germany for quite long this year. At some point in March I was so fed up with standing on icy cold train station platforms so I decided to take the car for a couple of days and rather endure the traffic jams. While that has certainly helped against the cold weather I noticed to my surprise after a week that my personal email inbox kept getting bigger and bigger and my blogging rhythm had significantly slowed down. I would have thought I'd implicitly reinvest the time I save taking the car into doing these tasks at  different time of the day. But no, that time just went somewhere else. So while commuting with the train usually takes longer than going to work by car this experience shows quite nicely that it is definitely not wasted time at all. Quite the contrary. In other words, working on these things while on the move is not limiting due to less space, more noisy environment, etc. but rather enabling!

In a previous post I've been looking at the pros and cons of my recent switch from Symbian to Android. One of the reasons to go for a dual-device strategy and still keep a Symbian device for taking high quality pictures and for road navigation is that I haven't found an Android device yet that comes close in either of these categories. As far as navigation is concerned here are some more details why:

Note by the way, that I am comparing Google Maps to the Symbian version
of Nokia maps and not the Windows phone version. I'm not familiar with
the Windows phone version of the program so I have no idea how it
compares to the Symbian implementation.

Before listing the cons I'd like to mention one feature I really like about Google Maps which is not implemented as nicely in Nokia Maps on Symbian: Real time traffic situation overview that is updated every couple of minutes. Especially for my daily commute I am now checking regularly while on the road if there's a traffic jam at two neuralgic points and take an alternate route before getting stuck. It works perfectly!

On the other hand, there are quite a number of features that are much better implemented in Nokia Maps for Symbian:

Offline Routing Capability

Let's bring up the biggest issue first. I travel a lot to foreign countries and roaming charges for data are usually highly prohibitive. In other words there is no way I can use Google maps abroad as it requires a data connection to download maps for car navigation or using it for guidance while on foot. For Nokia Maps on my Symbian device I have maps of all the countries I travel to on the device. Sure, that takes a couple of gigabytes of flash memory but there's more than enough in today's devices.

Routing

The routing algorithm in Google Maps is a bit strange and has led me several times through cities instead of using the bypasses which might not be as direct but much faster due to no traffic lights and city speed limits. Also in my home city, when I used navigation just to see what it would do has let me to the destination via roads which were neither direct nor optimal. Doing the same with Nokia maps has found the direct and best way. So still a bit of work to do for the Google team here.

No Speed Indication

Another thing which I like very much when being guided by a navigation system is to see the speed as calculated by the GPS receiver, which is much more accurate than my car's built in speedometer and also closer to other information such as routing and and speed limit data. Unfortunately Google Maps in navigation mode doesn't show the current speed.

No Speed Limit Indication

What I really have come to like in Nokia maps is that it shows the current speed limit next to my current speed and starts changing the background color of the speed indication to red and also gives an audible warning if desired. From my experience that maximum speed limit indication is very accurate. In Germany, where speed limits on the freeway changes every few kilometers for some reason or another it's easy to miss a speed limit sign just before a speed camera… This feature has saved me tons of money already and relieves me of being constantly on the lookout for speed limit signs. Unfortunately that's not available in Google maps yet and a real killer feature for me!

No Lane Assistant

Next in the list of missing features is the lane assistant. Nokia Maps and most other navigation systems that have been around for some time indicate to the driver in cities and at freeway exits which lanes to to take as this can sometimes be confusing. While not a must have feature for me it helps orientation in crucial moments.

No Distance Indication

Google likes to show the approximate time to the destination. That's nice but I'm an engineer, I like the hard facts, I want to know the remaining kilometers or miles. In Nokia Maps the display can be switched between the two.

Navigation in Tunnels

An important feature when driving through tunnels is that the navigation system keeps updating the approximate position even when no GPS signals is available as otherwise one easily misses exits that come right after the tunnel. A couple of years ago Nokia Maps didn't have that functionality and I was really happy when they added it. Unfortunately, Google Maps doesn't have this feature so far. Which means missing exits…

Horrible Pronunciation of Street Names

I usually disable voice guidance and just use the map. However, there are some exceptions during which I use voice Guidance. I use an Android device with the language set to English and Google maps assumes I want to hear the direction announcements in English, too. While this is true in general it unfortunately also announces the street names in English no matter in which country I am. To a native speaker, German or French street names with English pronunciation just hurts. Sorry Google, I'd really like to be able to switch that off if the maps application can't pronounce street names correctly and just be audibly informed which direction to go and when to make a turn. No pronunciation torture, please!

There we go. While some of the reasons are not really a show stopper, the missing speed indications in combination with the sub-optimal rooting and missing country-wide offline capability will make me stick with my dual device strategy for the foreseeable future.