No users in GDM list on FreeBSD? Here’s a fix

14 May 2010

So today GNOME finally finished compiling on this Compaq Evo N610c laptop which I installed FreeBSD 8.0 on the other day. It only took about 3 days to compile. (Only! Mind you, it pulled in all sorts of stuff, like Epiphany, which includes WebKit.)

After making sure GDM would come up on startup by adding this to /etc/rc.conf

dbus_enable="YES"
hald_enable="YES"
gnome_enable="YES"

(For some reason, lshal wouldn’t run if gnome_enable="YES" was the only line.)

…I was dismayed to discover that there were no users showing up in the GDM login form. Not even the “Other” option was available to let me log in manually.

Frustrated, I went to search Google. I started typing “freebsd gdm” and then Google Suggest popped up:

FreeBSD GDM no users

Looks like I’m not the only one Googling for that. Turns out I couldn’t find anything on Google — nobody seems to have been bothered to write anything up in an FAQ (which is why I’m writing this post).

On the offchance, I looked in /var/log/messages, and saw some messages quite like the following:

console-kit-daemon[60290]: WARNING: kvm_getenvv failed: cannot open /proc/60378/mem

Turns out FreeBSD doesn’t mount /proc by default, but it is required for GDM to work properly (and, I’d hazard a guess, OpenOffice.org and a whole lot of other stuff). You can easily enable procfs by adding this line to /etc/fstab:

proc /proc procfs rw 0 0

Then, reboot (or if you’re a clever clogs and mounted /proc by hand with mount, restart GDM /usr/local/etc/rc.d/gdm restart), and you should see the users in the login form!

We want YOU to pick a new name for Python-iView

21 April 2010

Uncle SamAs I mentioned in the original post that naming Python-iView was a bit haphazard. It was a “working title” because that’s what it is: an iView client for Python.

However, “Python-iView” is a pretty bland name, and it also looks funny among all the other python-* packages in Debian and Ubuntu (which are supposed to be libraries, while python-iview isn’t just a library).

So, here’s your chance to suggest a new name for Python-iView. Please submit your suggestions in the following box:

Voting has closed!

While I don’t necessarily need “iView” in the name, it is important it’s instantly recognisable as an iView frontend. Because the original intent of Python-iView was to be a lightweight interface, “iViewMinus” was one name I had in mind (though it’s somewhat tacky).

One other thing to keep in mind is that there are now Boxee and XBMC plugins (with an equally boring and generic name) based on Python-iView. I’ve proposed to Andy that the two plugins get merged upstream as part of Python-iView itself, so a new name that could take that into consideration would be awesome.

So put your thinking cap on. Feel free to suggest any name that pops into your head into the above box. Suggest “Python-iView” if you don’t want me to change the name. You can even vote multiple times. Or discuss in the comments below.

Update to Python-iView: new SWF verification keys

13 April 2010

Python-iView has received another update today, as a result of the ABC changing their SWF verification keys without notice.

The usual to get the update:

$ bzr pull

Don’t forget, Doctor Who is on iView at midnight this Friday. I’m excited! :) (What I presume that means is 00:00 on Saturday, but I think I’ll check at 00:00 on Friday just to be sure.)

Python-iView with 341 update fix

31 March 2010

ABC iView has now been updated to version 341, and with it came an update that broke backwards compatibility. Thanks to Jim, this has been fixed already in Python-iView.

The usual trick to get the update

$ bzr pull

By the way, Python-iView is now able to produce .deb packages. That means an apt repository for Python-iView could be coming soon. :)

Multicast versus IPTV

24 February 2010

I’ve been hearing a lot of buzz about IPTV lately. It’s something that is exciting, useful, and inevitable.

As I understand it, IPTV is defined to be a live television service delivered over multicast (usually RTP) over a broadband Internet connection. Multicast has an advantage over normal traffic (“unicast”) because it avoids the duplication of traffic. Only one copy of the data is ever sent.

TPG currently offer 19 channels over an IPTV service, and TransACT allegedly offer over 50. iiNet is “on the brink of IPTV launch”. There are rumours that Internode are investigating something similar too.

That last paragraph should have triggered alarm bells in your head. It did for me, but maybe I’m just a cynic. Let me explain.

I asked myself: why are the ISPs providing the IPTV service? It sounds wrong to me. I’ve tried to come up with an answer, and my conclusion is that it is because of two reasons: (1) infrastructure (multicast is virtually non-existant in most production networks) and (2) content lock-in.

Having the ISPs provide the infrastructure for the IPTV service (marketing, encoding, distribution, etc.) means the ISP will likely sign a contract to exclusive usage rights with the TV partner for each channel they will provide. If iiNet sign an exclusive deal with Sky News, they sure as heck ain’t going to let Internode or TPG also put the content on their networks.

The infrastructure would also be duplicated. Each ISP needs their own TV receiving equipment (likely a few satellite dishes on top of their data centre), encoding equipment, marketing, private IP multicast network, and whatnot.

With regards to content lock-in, this will also mean that the ISP you choose to use will determine what IPTV channels you are able to watch. Conversely, what IPTV channels you want to watch will determine which ISP you will sign up with.

That sounds all rosy, until you consider that I am not restricted on what websites I can visit based on what ISP I am with. I can watch YouTube or ABC iView from any ISP in Australia. Sure, some ISPs offer better services than others, faster speeds, or more reliable connections, but it’s just the one Internet. This is because the ISP is not in the content provider role. They are merely the gateway to the Internet — the Internet service provider (now where have I heard that term before?).

The way IPTV looks like it is heading is shifting the ISP onto the content provider role. As I’ve already said, this means the service is delivered over the ISP’s private network, available exclusive to that ISP’s customers, and not over the Internet. That’s a Bad Thing™ in terms of net neutrality.

If an ISP “rebroadcasts” content from an IPTV channel that another ISP has signed an exclusive deal on, that would be a copyright violation.

But that still doesn’t explain the title of my post: “Multicast versus IPTV”. The above isn’t actually the crux of what I wanted to get at (apologies to the reader if you’ve managed to read this far in great detail).

I’m supportive of multicast in general. Combined with IPv6 (each /64 subnet has a corresponding multicast subnet), multicast opens up the doorway for anybody to serve high definition audio and video to the Internet at large without the need for exorbitant amounts of bandwidth up their sleeve.

But that’s public multicast. These “IPTV” solutions will be, and currently are, deployed on private multicast networks. On the plus site, private multicast networks mean it is easier for the ISP to deploy the infrastructure — it’s much easier to only have to worry about your own network, than also have to worry about interfacing with others. But it also means less incentive to deploy a public multicast infrastructure, and less incentive for content providers (such as TV networks) to provide their services over multicast themselves. It’s a chicken-and-egg problem.

We don’t need ISPs to “provide IPTV services”. We need a decent multicast network (preferably IPv6) that all Australians can access, so that TV stations themselves can provide the multicast streams with the knowledge that a large percentage of Internet subscribers are able to access their content, and that channel availability discrimination does not occur based on what ISP you choose to sign up with.

That’s the crux of what I’m getting at. I’m sure someone will come along and say “but but but…they have a right to sign exclusive contracts and deliver only over private networks”. My response to that would be that just because you have the right, doesn’t make it right. Nor left. :)

Thoughts?