If the user really needs to have a program output sound right until Linux goes into suspend mode, and then continues where it left off when resuming, then ALSA is (currently) the only option. I personally don't find this to be a problem, and furthermore I doubt it's a large percentage of users that even use suspend in Linux. Suspend in general in Linux isn't great, due to some rouge piece of hardware like a network or video card which screws it up.

So we should be using OSS because the author doesn't use suspend on his computer?

The article is just a big rant about how difficult he finds ALSA to develop for, how he doesn't understand the benefits of a user-space audio stack as found in Windows Vista and with PulseAudio empowering Ubuntu and other distributions.

This is why we have the Internet, please use and develop new and interesting applications, but they should be webapps. This completely avoids the issue of modifying the desktop and allows immediate availability to everyone in the company.

Being an IT person is being a computer janitor. If you are doing the job properly you are simply unclogging the tubes or restocking printer paper. Every machine should be imaged and locked down with something like Microsoft SteadyState, when a user has a problem it's either a reboot, re-image, or a hardware replacement.

The problem might stem from merging IS and IT jobs into the same position with no distinction being made. IS projects should be handled in a more formal manner than re-stocking a printer but because defining such an interaction is widely open to interpretation it has been taken to the users advantage. You need to take ownership of that interaction and make it clear the difference between such projects and cleaning the tubes.

So instead of offering one browser that can be configured by Group Policy in an Enterprise IT deployment they offer a web service to generate hard-coded branded browser installers? Sounds like a lot of work to avoid implementing what IT managers really want.

Sun is just as bad or worse than Microsoft by implementing incomplete standards leading to the same incompatibility that ODF is supposed to resolve.

Sun should write out formulas in ODF 1.1 format, using the legacy "oooc" namespace prefix that the other vendors are using. Remember, the other vendors are using that namespace specifically for compatibility with OO's ODF documents. This is the current convention. To unilaterally switch, without notice or coordination, to a new namespace, is not cool. When ODF 1.2 is an approved standard, then we all can move there in a coordinated fashion, to cause users minimal inconvenience. But the above table clearly shows the confusion that results if this move is not coordinated. I know OO 3.01 has an option to save in ODF 1.0/1.1 format. IMHO, this should setting should be the default. I'm not sure if the Sun Plugin has a similar configuration option, but I hope it does.

It's a fallacy with US banking, both cashiers cheques and bankers drafts are as useless as regular cheques for guaranteeing payment. Both can be bounced by the originating bank for a variety of reasons. Cashiers cheque are generally more dangerous as your account can be credited earlier, as required by federal law, than when the clearance occurs so you account can appear in credit but later in debit.

Performance wise, XMPP bills itself as high performance messaging, but the developers are focused on the WAN. AMQP comparatively is ultra-high performance messaging with optimisations for the LAN.

This is confusing as for many projects there is limited need for ultra-high performance data rates. Numbers of the range 100,000 messages per second with latency under one millisecond. At this rate special engineering methods are required, XML, SSL, compression are too slow, focus is upon zero-copy processing, i.e. accessing and updating data in place, because the memory-bus is too slow to perform copies.

There is a discussion between one AMQP and one XMPP developer that sums this up:

>> So AFAIU, XMPP is not a serious candidate for high-volume messaging, right?

No, wrong, as with anything it will all depend on the capacity of your servers and the bandwidth you have available at your disposal, there is nothing stopping high-volume messaging over XMPP if you control the infrastructure.

http://www.mail-archive.com/jdev@jabber.org/msg19403.html

Another major advantage for AMQP is message routing. You can define which messages are routed to different sites by their content. Again this is an unusual requirement for many projects as they do not exist on such a scale for this to normally be an issue. The closest equivalent is SMTP routing by domain, you can find more discussion on this InfoQ article:

http://www.infoq.com/news/2008/08/amqp-progress

The main focus on AMQP is to appear a qualified messaging protocol for certified or guaranteed messaging with the necessary tools and support from vendors to promote its usage. XMPP can do a lot of the AMQP functionality already, but most of it is optional functionality rather than a primary design goal. If AMQP support appears in the Visual Studio Development System together with MMC modules for monitoring and administration, for example, its adoption could rapidly grow.