hulu.com works on FreeBSD 8.3 with updates

outpaddling · Feb 24, 2013

Just putting this out there so people are aware.

I got hulu.com working on FreeBSD 8.3 with sysutils/desktop-installer by doing the following:

As root:

1. Update www/linux-f10-flashplugin11

If you're using the 8.3-RELEASE ports snapshot:
Change PORTVERSION 11.2r202.270
make distclean makesum deinstall

Downloading the latest port framework into this tree won't work due to new features
not present in the 8.3-RELEASE tree, so just change the version as described above.

If you're using the latest ports tree from portsnap, you shouldn't need to update.
(Of course, these ports may not be compatible with binary packages from 8.3-RELEASE,
so you'll have to install everything from source.)

2. Deinstall www/nspluginwrapper if it's installed.

3. Re-run desktop-installer and select Linux Flash when asked. This will install the
necessary packages (including Gecko Media Player) and links.

As each normal user:

1. nspluginwrapper -v -a -i

2. Start firefox

3. Verify flash version is 11.2 r202 by going to about:plugins

wblock@ · Feb 24, 2013

outpaddling said:
As root:

1. Update www/linux-f10-flashplugin11

If you're using the 8.3-RELEASE ports snapshot:
Change PORTVERSION 11.2r202.270
make distclean makesum deinstall

Beware: realize that by accepting that distfile and declaring that the checksum is correct, whatever it is, you are bypassing security checks. That is the latest version in ports now, anyway, so normal port upgrade procedures should be adequate.

outpaddling · Feb 25, 2013

wblock@ said:
Beware: realize that by accepting that distfile and declaring that the checksum is correct, whatever it is, you are bypassing security checks. That is the latest version in ports now, anyway, so normal port upgrade procedures should be adequate.

That is an important caution, so thanks for adding it. Users should generally try to verify the trustworthiness of the source of distfiles when altering a port framework this way, but given that this alteration uses the same distfile as the current port, it should be safe in this case.

Also note, however, that normal port upgrade procedures such as portsnap may require rebuilding all installed packages from source. The latest ports are likely to require newer versions of some prerequisites than the -RELEASE packages provide. Using the latest binary packages instead of the -RELEASE packages is also risky, since they don't all come from the same ports snapshot. Only packages from the -RELEASE snapshot are guaranteed to be compatible with each other, since they are built during a ports freeze.

If you don't mind upgrading everything from source, then portsnap may be the way to go. I maintain a lot of FreeBSD boxes, though, so I don't have time for that, and prefer to use the latest -RELEASE and binary packages. Hence, in rare cases like this one, I'll hack the odd port that absolutely needs to be upgraded while keeping my -RELEASE ports snapshot in place.

kpa · Mar 1, 2013

outpaddling said:
Using the latest binary packages instead of the -RELEASE packages is also risky, since they don't all come from the same ports snapshot. Only packages from the -RELEASE snapshot are guaranteed to be compatible with each other, since they are built during a ports freeze.

This is not really true. The release packages are provided on as-is basis and are meant to be used only as a last ditch solution if no other packages are available for installing. The ports freeze is meant to minimize the possibility that the packages have incompatibilities but it's not a guarantee. Not to mention the security updates to ports/packages after the time of the release. The latest binary packages are ALWAYS recommended over the frozen in time release packages.

outpaddling · Mar 6, 2013

kpa said:
This is not really true. The release packages are provided on as-is basis and are meant to be used only as a last ditch solution if no other packages are available for installing. The ports freeze is meant to minimize the possibility that the packages have incompatibilities but it's not a guarantee. Not to mention the security updates to ports/packages after the time of the release. The latest binary packages are ALWAYS recommended over the frozen in time release packages.

I stopped supporting the use of binary packages outside of -RELEASE in desktop-installer because the setup is unlikely to complete without intervention when using them. In fact, I can't recall a case where it didn't fail at some point due to some prerequisite package being too old or too new. Managing a large number of systems requires automated installs that can run largely unattended.

What I personally recommend is either:

1) Use packages from -RELEASE and upgrade the OS to the latest release frequently.

or

2) Use portsnap and (re)build everything from source.

I'm in the camp that favors backing up, erasing the disk, and reinstalling frequently to clear up the bit-rot that every system accumulates. This is what desktop-installer is designed to facilitate. I take this approach with most machines now, and upgrade them every time a new release is available. With a dependable set of binary packages, the upgrade process only takes an hour or two per machine, most of which is scripted package installs that don't have to be watched.

If one has to deploy to multiple machines and wants to use the latter method, I recommend taking a snapshot using portsnap, distributing it to all machines, and building your own packages. That was the approach I used when supporting 30+ FreeBSD workstations for an fMRI lab some years ago, where backing up and restoring the huge amounts of data made the upgrade process unacceptably long.