Skip to content
A scene from Ireland

Opinion

  • in Opinion
  • 3 min read

Returned my Dgtec HDPVR5009 to Dick Smith

Last week I bought a "Dgtec HDPVR5009" High-definition Personal Video Record from Dick Smith electronics. Today I returned it, which is a bit disappointing.

It should be a reasonably adequate device. It doesn't have AV input, so I cannot digitise old videos, it doesn't have USB for external storage or network or any of those frills. But it has twin HD DVB-T tuners and 500GB of internal disk drive, and HDMI output, so it should do basic recording and playback OK. But it doesn't.

Also there seem to be a lot of rough edges on the software, enough to make me feel it would constantly annoy me.

The big problems were:

  • While playing a recording the audio would sometimes drop out. At first I thought there must have been a signal problem during recording, but the video was fine. Then I discovered that if I rewind and play again, the audio will be there. Even "pause then play" will bring back the audio. But sometimes it only comes back for a minute to two. The audio is there, it just wasn't playing. This didn't always happen. Often I could watch a recording with no problems. But the fact that it happened at all is a worry.
  • Sometimes - possibly dependent on the particular channel I was watching - the audio and video would be a fraction of a second out of sync. When you can see the lips of the person who is talking, this can be very disconcerting. When I want the show using the DVB-T receiver in the TV, it is perfect, when I watch through the Dgtec, it was bad. Again, this wasn't all the time, and may have been fairly rare. But I don't want a device that does that.

Those were enough to convince me to take the device back. Other problems are relatively minor but still an annoyance.

  • It was awkward to switch between watching the TV live, and watching the on-going recording. There is a 'freeze' button which freezes the image. But when press it again, it doesn't continue from where it was, but rather jumps forward to the current time.
  • When you do switch to the recording of the current program, you can fairly easily jump forward towards the end, but you can also very easily jump past the end which wraps around to the start again. Going back from the start doesn't take you to the end. So it is quite hard to fast forward to the end of the recording, which is the moment currently being recorded.
  • There is a nice feature where you can 'mark' the current point in a recording, and it shows as a little mark when you show the slider control for navigating around the recording. However there is no way to jump to the next/previous mark, so the marks are fairly useless. At least, I couldn't find a way, and the documentation didn't list one.
  • The device supports a list of 'favourite' channels so that it is easy to jump to the channel you want without having to hunt through a long list. However when creating a timer event to record a program, it doesn't allow access to this 'favourites' list, and it doesn't default to the 'current' channel. So you still have to hunt through a long list
  • When you record a program, it chooses a name for the file base on the name of the program being recorded. But if you want to change this name it isn't easy. Despite the remote having a mobile-phone-like keypad with 3 or 4 letters per digit, you cannot use this to enter a new file name. You have to use arrow buttons to walk around an on-screen key board, and press 'select' for the letters you want. And don't bother trying to enter a space, you cannot.

So, a long way less than perfect. And while the price-point ($400) would lead you not to expect perfection, it was to me sufficiently far from perfect to be unusable. Your mileage might vary....

Linux.conf.au 2009 - Hobart Tasmania

I recently had the pleasure of attending linux.conf.au 2009. When I go to these conferences I like to write a trip report to share will my colleagues. And having written it, I thought I would share it with you too.

Enjoy.

linux.conf.au 2009 was held in late January in Hobart, Tasmania - the southernmost city in Australia. With a population of around 200,000 it is big enough to offer all the facilities conference attendees would require, without being so big that it takes an hour just to get out into the countryside. And the country side is well worth seeing as Tasmania has much beautiful scenery and wilderness to enjoy.

The talks covered a wide range of the sort of technical and social commentary that you would expect from an Open Source based conference. From providing low-infrastructure small town telephony through mesh networks (google:Mesh Potato) through the use of wikis in documentation and community building to the difficulties of building a robot to play a clarinet, there were talks for all tastes.

One theme that emerged for me (possibly because I attended a number of talks at the "mobile devices" mini-conference) relates to issues with Embedded Linux.

A good tongue to speak in.

So, Christian: You think you would like to be able to "Speak in tongues"?

Let me suggest a good tongue to start with.

They say "Money speaks all languages" so if you speak with money, you can speak in all tongues.

I encourage you then to speak your worship of God with the language of Money. Give, as Christ has given so much to you.

Then your 'speaking in tongues' will truely be a blessing to many (including yourself) and will be glofirfying to God.

Free Indeed

What would you say is the biggest difference between "The Western World" (by which I mean Australia, NZ, UK, USA, Canada, Western Europe, and similar countries and their cultures) and the rest of the world?

I think one answer would have to be freedom. The US in particular seems to make a big deal of individual freedom, but they are by no means alone in enjoying it. Most western cultures do, while many African, Asian, and East European countries do not enjoy as much freedom (I'm not sure about South America..)

By freedom I mean many things. Freedom to speak one's mind in public. Freedom to worship as one pleases. Freedom to choose how to uses one's time and property. Indeed, freedom to own property. It also includes the concept of a free market to buy and sell goods and services.

Freedom from poverty, freedom from ignorance, freedom from curable disease are also important parts of freedom and whiile they may not be as prevalent in the west as we might like, they are much more prevalent thant in the rest.

So where does this freedom come from? The answer would seem to be "From Christians".

Spiritual Gifts of Spiritual People

One of the topics that often receives, and requires, teaching in the Christian Church is that of so-called Spiritual Gifts. This is hardly a new thing. Paul was teaching about it in the first century to the Corinthians (1Cor12) and the Ephesians (Eph 4) and others (e.g. Romans 12).

But it is still an important thing to teach about as there seems to be much confusion about it. One of the divisions in the Protestant Churches of today seems to between the so-called "Charismatic" and "Evangelical" movements and a large part of that division seems to be based around the understand of spiritual gifts. This is particularly ironic as in the places where the New Testament particularly teaches about theses gifts, the over-riding focus of the section in on Unity within the church.

So why am I saying all this? Because I recently gained a perspective on gifts that I find very helpful. It seems to put things in the right context in that it focuses on people, and people are what God is really interested in: People and their relationships to Him and to each other.

My observation is simply this: That some of the most significant gifts that I have received from God are people. The greatest gift was certainly a person: Jesus. Other gifts are very often people: people who encourage, or teach, or challenge, or care, or reveal God in some other way. I wouldn't say that gifts from God are exclusively people: God is much bigger than that. But it seems that when God wants to speak or act in someone's life, he prefers to do it with another person.

  • in Opinion
  • 3 min read

Why I don't like ACLs and extended attributes

I really don't lile ACL's and extended attributes in filesystems. NFSv4 supports them and it makes it ugly. More and more filesystems are supporting them and it is just added complexity that really is the wrong way to go.

But me just saying that doesn't prove anything. So I should try to convince you, dear reader.

  • in Opinion
  • 9 min read

Where Unix went wrong - filesystems - access control

This is one in a (possible) series where I complain about design decisions in Unix. Unix has, on the whole, a very good design, so mistakes stand out rather clearly.

Today's article looks at "Access Control" for files. The "ugo" access control in Unix doesn't seem all that bad until you look at the generalisation known as ACLs - access control lists. Once you see them you have to realise that something was fundamentally wrong to start with.

  • in Opinion
  • 3 min read

A theory of meetings

Meetings often bother me. They are important an dcan be useful. But they also often seem to be largely a waste of time. I sit there day-dreaming or tapping on my notebook (very rude!!) waiting for something that is of relevance to me.

I've been thinking about this on and off and would like to develop "theory of meetings", or atleast part of one.

  • in Opinion
  • 3 min read

01170844

Beyond Pipes

Pipes are a great tool for connecting programs together. It is a real joy to be able to connected various Unix tools together in a pipeline. One of my favourite is

... | sort | uniq -c | sort -n

to get a frequency count of some collection of lines (often from logs).

It is worth noting that pipes are only one of the enabling technologies for this sort of thing. There are two others.

The first is the Bourne shell and derivative. The fact that the shell makes it easy to create pipelines is fundamental to their success.

The other is the common practice of having program receive and generate un-decorated line-oriented data. This 'common language' for passing data around is essential for pipelines to work. It is worth noting that while line-oriented is very standard, having fields in the lines is very ad-hoc. Many commands allow you to act of fields, but they all do so in different ways. If you compare sort, cut, uniq and others you will see a complete lack of uniformity. This something that a successor to pipes would need to address.

So a successor to pipes needs an IPC primitive (the pipe), and platform for building applications (the shell) and a standard data representation (line == record). It also needs a market - a reason for existence.

My own feeling of the market is for interactive tools. With pipe line, there is no opportunity for a conversation between elements of the pipeline. There is no way to have a "server" which will respond to requests, or a client that can give more information. So interactivity would be my choice of market place. Note that this doesn't mean interactive in a 'human-interacts-with-computer' sense, but in a 'client interacts with server' sense.

This is by no means a new market - there have been RPC (remote procedure call) systems for decades. There is even CORBA which is designed to make parts easily interchangeable. But somehow they don't seem to have the same degree of use as pipelines.

I also think that the IPC primitive is already available. I see two primitives as being usable. One is loadable modules, and the other is Unix domain sockets.

Loadable modules allow the server to run in the same address space as the client, which should provide high bandwidth and low latency. It does require the server to be single threaded and to only server one client at a time. For many applications this would be fine.

Unix domain sockets are an easy way to create a connection between two processes, much like a pipe. It is better than IP sockets as there is natural permission checking.

That just leaves a suitable data format, and a usable platform.

Data Format

I think it would be a mistake to try to define how fields fit into records, what separator to use, and how to label fields. It might be worth doing this if we were trying to make pipelines better, but we are going beyond that.

I see that appropriate abstraction being a namespace line a filesystem. Each server presents a namespace. Each name can be "opened" and the resulting channel can be subject to "read" and "write". Each client sees it's own namespace, so that different clients don't affect each other unless that is the purpose of the service.

Whitelisting email

I have been following SPF for a while and have been thinking through the whole junk-mail control issue.

I have come to the conclusion that the only viable long-term solution is agressive whitelisting.

I have been having thoughts about setting up a local service to support whitelisting.