The Foursquare Blog

Each time the device powers off and restarts, it sets itself to use DHCP.

The device runs Linux under the hood, and even exposes the SSH port, but the accounts it uses are not obvious. And root is disabled.

To fix the device yourself, you will first need root access. The easiest way is described in this wiki page. Basically:

	ssh USERNAME_hipserv2_seagateplug_XXXX-XXXX-XXXX-XXXX@DEVICE_IP_ADDRESS
	sudo -E -s

The USERNAME is the name of the account you have created on the device, when using the usual Windows interface. The XXXX-XXXX-XXXX-XXXX is the PK Product Key located on the bottom of the device.

First, make it easier to gain root access by enabling root SSH logins:

	Edit /etc/ssh/sshd_config and uncomment:
		PermitRootLogin yes
	Set your own root password:
		passwd root
	Restart SSH:
		service sshd restart

Next, there is a bug in the logic of the /etc/init.d/oe-bootinit script's ensure_firstbootnetwork() function. The entire function should probably only run if the /etc/firstboot file exists, but there is an if/else statement that only checks this for the first half of the if statement. The else is where the DHCP overwrite happens.

By this point, though, your device has passed the first boot, so you don't need this code anymore. I commented out the entire block of code, and replaced it with something innocuous, just to avoid any shell issues with empty functions:

        echo do nothing > /dev/null

You'll want to be careful editing these files, since if you make a typo that prevents network boot, you won't be able to login to fix it.

It seems that Seagate has known about this issue since September, but there were no software updates that fix this issue. Using the web interface to check for updates, it claimed that the device was up to date. You may want to take this into consideration when making future purchasing decisions.

Good luck, and enjoy!

I'm partly willing to give PulseAudio the benefit of the doubt though, if only for the power saving potential. I find it disappointing that an entire daemon and library system has to be built on top of ALSA and OSS to achieve this, but since Linux has decided that mixing belongs in userspace, and that no floating point is allowed in the kernel (understandable), then mixing has to be done somewhere, and PulseAudio looks like a good attempt by a sane developer, who is saddled with working with the pre-existing sound mess that is Linux.

The library situation looks interesting... if you want to just program with a library and forget the low level, use libao or libao2 (libao2 comes from the mplayer guys). Libao is crossplatform.

Another library called libsydney is also intended to be crossplatform (Linux, Windows DirectSound, Mac, etc). I haven't looked closely into that, but it is probably worth a look.

See http://blogs.adobe.com/penguin.swf/linuxaudio.png for a graphic of other sound APIs and systems. As a programmer, I would aim for either programming directly to OSS, which is portable crossplatform, or use libao2. Maybe libsydney if it doesn't have too many dependencies. My needs as a sound programmer would not be anywhere near the heavy-duty, so these options would work for me.

As for PulseAudio's state of readiness, I think there is a definite reason why it ain't at version 1.0 yet! :-) But that's not a bad thing. For stable-loving users like myself, it is probably worth waiting for a few distro release cycles before the bugs are worked out to a satisfactory degree. Newer PulseAudio releases will even stress ALSA drivers in new and interesting ways, so I expect there will be a strain on the sound system for a good while yet, from the applications right on down to the kernel.

If you don't need sound mixing, don't use PulseAudio yet. If you don't need power savings, don't use PulseAudio yet. If you use a laptop on battery then PulseAudio may be very useful, but you may need a good chunk of memory to support it, and it will pay to stay as up to date as possible, with kernel, distro, and PulseAudio.

From a power standpoint, there are reports of PulseAudio not even showing up on powertop, even while playing music, which is a good thing. I don't know how mpg123 + ALSA or OSS would compare.

There's a lot of flameage out there regarding ALSA and OSS3 and OSS4. It is easy to get caught up in it, and yes, I was caught up in it too... but my style of getting caught up in something usually involves me wasting many hours on research and reading to get the facts, and at the end of all this, I'm feeling less harsh with everyone, even though my mpg123 + ALSA configuration sometimes uses 40% CPU on a P4. (grrr!) :-) I can see the history and the reasons why Linux sound has evolved the way it has, and while some things still look unfortunate, they are understandable, and people continue to work on improving the situation.

I must say, though, that a piece of software going from "open" to closed, such as OSS3 did, can cause much disruption in the Free Software community. Even KDE and Gnome were arguably split due to licensing issues, even though they evolved in quite different technical directions as well. I think it would behoove the Free Software community to be more watchful of such situations, and guard against such collateral damage. The side effects can last for decades.