As you probably noted, I’m not very active in a matter of FreeBSD project. The reason is that I’ve just changed a job, the term is almost over in the Uni and I’m going to have a lot of tests and exams. I get very tired because of it and simpe don’t have enough physical resources to hack on FreeBSD. I’ll try to update some of my ports during this weekend (BMPx is first in the queue and then gnutls and friends).

I was trying to make mplayer play wmv video on my amd64 and found the interesting topic on ubuntuforums: http://www.ubuntuforums.org/showthread.php?t=140565&page=3. It has some instruction how to patch the ubuntu package and has a patch attached as well (the original author of the patch is jserv).

So, here’s a quick guide how to patch your mplayer port:

2. fetch http://people.freebsd.org/~novel/files/mplayer-wmv3.diff.gz (you need to register on ubuntu forums to fetch the patch so I decided to upload it on my site)
   
3. gunzip mplayer-wmv3.diff.gz
   
4. cd /usr/ports/multimedia/mplayer && make patch
   
5. cd work/MPlayer-1.0pre8 && patch -p1 < /patch/to/mplayerwmv3.diff
   
6. make install clean
   

You should be able to playback wmv videos after that (and you don’t need win32codes, etc). However, it doesn’t work with WMV9.

About a year ago I wrote a patch which makes it possible to add ‘descriptions’ for network interfaces. You can read the details in kern/83622. Today I’ve updated the patch and submitted follow-up to PR. It’s sad that nothing moved towards committing it. Although this feature is very useful for me. On one of the boxes at work we have:

r1[~]# ifconfig | wc -l
513
r1[~]#

It’s almost impossible to keep all that stuff in the head and being able to set description is very nice. It would be sad if I had to maintain this patch out of the tree…

I’ve been hacking on ipfw for last two days. I wanted to be able to set tos and dscp for packets matching rules and catch packets by dscp as well (it’s possible to catch packets by ToS value in ipfw already). I found a patch which did this for freebsd 5.x, though I had to rewrite most parts of it and added some additional features as well.

So now I’m able to do the following things:

dscp AF32 tcp from any to any in via fxp0 <- that’s a rule for setting dscp to ‘AF32’ for all incoming packets on fxp0

count tcp from any to any dscp AF11 in via fxp0 <- that’s a rule for counting packets with dscp = AF11

It’s also possible to change tos like ipfw add 100 iptos reliability all ….. Values for iptos are the same as descibed in ipfw(8). A list of values for dscp is here: http://www.iana.org/assignments/dscp-registry

If you’re interested, you can grab patch for 6-STABLE here: http://people.freebsd.org/~novel/patches/freebsd/ipfw_tos_dscp_20060823_1.diff

Update: http://people.freebsd.org/~novel/patches/freebsd/ipfw_tos_dscp_20060824_1.diff

Update 2:  kern/102471

There were a lot of discussion on FreeBSD ports tree last few month. For example, it has been noted there’re a lot of unmaintained ports (freebsd-ports@, mid ) and ports collection is very large (freebsd-ports@, ). So, it looks like a number of ports grows much faster than a number of maintainers. I have a few thoughts on it I want to share with you.

2. New ports
   

IIRC, some time ago it was decided not to accept new ports where MAINTAINER=. It’s obviously a good idea, though I’m not sure if all ports committers follow this recommendation.

But there’re some more problems. First of them: there are a lot of people submitting “useless” ports, e.g. a search engine for mails using PostgreSQL. Man, it’s crazy! But it’s not the worst case, there are some ports I barely believe somebody actually uses. People submit ports just because “wow, new thing, dunno why I need it but I’ll make a port”. I have a strong opinion: if you don’t need this app, don’t create a port for it! You might say: it’s good for end uses to have as much ports as possible. Yeah, in general it’s true. But take into account that if a person actually doesn’t use a ported app, the port will be bad. Just imagine: end user installs some software from ports and sees that the software doesn’t work, because a maintainer e.g. updates the port, but doesn’t even launch it and that way doesn’t know that this software core dumps on start for example. End users asks maintainer: it doesn’t work, help me! And maintainer says: I don’t know how it works, I don’t know the programming language it’s written in and finally I cannot reproduce this bug ’cause I don’t use this app! What we get as a result: sad end user and one more useless port. So, how do you thing, is it possible to make a good port if you don’t use the app? And what is better – bad port and no port at all?

2. Ports without maintainers
As it was mentioned above, many ports have no maintainer. I think that once port lost its maintainer, it should be scheduled for removal in, say, half a year. Instead of it we do the following: we leave things as is. Futhermore, some people start local mini-campaigns fixing such ports. They do updates, they fix master sites and stuff. It’s bad. All the reasons from part 1 applies here too + they don’t even feel responsable because they actually don’t maintain that port.

So, I think users vote by feedback/submissions/contributions in open source. If nobody wants to adopt a port, it should be removed. If user has not enough skills to adopt existing port or create a new one, he/she should ask for help some more skilled users. And that more skilled users should not create ports only because their skills are high enough to do it.
IMO, having 5000 ports in a very good shape are way better than having 15000 ports in a bad shape.