Yup, the Squeezebox family of products is your best bet. It integrates fine with your existing setup (you just need a free aux input on your amp) and can be standalone (Standalone boom box). All of them support WiFi or Ethernet. You can operate each station completely independently or you can synchronize them (same music everywhere). If you have your musick already ripped to mp3 and your tags are clean then most of the work is done. The product family is about a decade old, so it has some history and the bugs are gone.

In addition the server software is open source and quite portable (Windows, Linux, even some NAS boxes are supported). There are plenty of plugins and extensions. Internet Radio is well integrated too.

It is not cheap, but none of the alternatives are cheaper or better either.

Markus

And it has the advantage that Euro-Plugs fit into it.

On neat trick is to buy a Swiss power cord and rip out the third (ground) pin. You get a power cord which fits in all Euro sockets without adapter.

The Swiss plug is the one labelled 'Type 3' on the world map of the Gizmodo article above.

Markus

Yes, good enough is the enemy of perfect everywhere. And I suppose if you know your hammer well you tend to see problems as nails.

In my area there in not much Sun high-end left (1-2 E20k) and plenty of fat IBM boxes (>50), this might explain part of the lack of customer interest...

Markus

I never used Solaris zones, never used the similar AIX 'workload partition' either. But I'm aware of what they do and and how they work.

I (my) experience, if you need isolation, going the entire way and use a separate VM/LPAR with its own OS is the better solution. This is why I am missing this tech on Sun's high-end servers and don't understand that they are not even seem to plan to catch up in the future.

Markus

Solaris Zones, as I understand them, isolate applications from each other, but all are running within/on top of the same Solaris instance. As soon as you want to run different OS levels for the different apps or environments you are out of luck.

For example a new OS maintenance level is usually tested for a while in a test environment before being applied in production. Zones don't help here.

Often we have also incompatible prerequisite requirements of different apps (3rd party apps are terrible in this respect). App1 need at least maintenance level 123, while app2 has not been tested yet on this level and is not supported. If you give each a separate OS image, then you can give everyone what he wants.

You pay a small hardware price: A OS disk (30G) and some memory (512M), but you remove a ton of versioning update scheduling constraints.

Markus

I'm missing indications about better virtualisation features, like I'm used to them on IBM gear. These days all high end installation I see are running tens to hundreds of virtual machines on a single server. It looks to me that virtualisation in this scale is not even on the roadmap.

Markus

I've lived a similar story a while back. I was using a perl module from CPAN for a customer project. During the implementation I found some bugs/limitations. After getting in contact with the maintainer he sent me some patches to fix my problems. I used those and my project went into production.

A couple of years later we did migrate the application to a new server and I reinstalled the perl modules from CPAN. I found that the patches I got never made it to the CPAN repository. I still got the original patches and used those to get my project shipshape again.

In parallel I tried to get in contact with the original maintainer, but I never got a reply. It looked like he dropped off the planet. After a while I applied for co-maintainer status of the module on CPAN. This was granted when I could plausibly demonstrate that I tried to talk to the original maintainer. Since then I'm now the 'official' maintainer of the module and do integrate patches and help users.

We don't know about your modul en and its infrastructure (homepage., mailing list, etc.). Perl modules live on CPAN, so it is a good start to start there. You'll have to see where your program lives and go from there.

Markus

I don't understand all the hate for Bill.

In my view he is the responsible for some of the unethical beaviour of Microsoft. I'm thinking of the famous 'if DRDos then crash' in Windows 95, among others.

Markus

I'd move on. Not for any particular feature, but to stay closer to the mainstream for the next years. The 2.4 kernel, not for any technical reason, becomes increasingly exotic as people move on to 2.6.

You'll have to maintain your existing 2.4 skills for another decade when all others have moved.

Markus

Over here in Europe we have seen the advantage of high gas prices lately. When the barrels went from $40 to $160 (up 400%) our gas at the pump went up from CHF 1.4 to CHF 2.0 (up 40%). Still a hike, but not something to change economics of driving dramatically. The high taxes, besides funding decent roads and non-collapsing bridges, provide a nice cushion against the volatility of the oil market.

Of course, due to the higher price level our cars are in general smaller and more economical anyway.

Markus

What exactly can you do only with firewire ? Is a USB-Firewire converter cable not be an option ? The only time I even needed Firewire is for my Sony DV camera who only has a Firewire port. Firewire has some advantages, but since USB 2.0 they look largely theoretical to me. Where is the beef ?