That's always assuming that they give it a chance in the first place. Small vendor/open source vs Safe Big Vendor - easy to see where the IT Managers who buy into the big names are safe/good products are going to put their money.

Only if you can get around secure-boot...

Personally I think its the basis of long term thinking for any company (which is what the BBC is but with different shareholders) - gain market, sell your goods, make profit, support those dependent upon you whom you are dependent upon.

Funnily that could almost sound like a reason for DRM if you believed that DRM would help achieve selling goods - which is why of course companies use it regardless of whether the reasoning to use DRM or not is flawed.

Yes, the BBC uses a lot of open source and I'm sure would relish a world where it was easy to publish media without DRM, however, I don't see any reason, from the BBC heirarchies perspective to actually support the stance you are saying they should take when there is some risk for the BBC in doing it. Yes it might encourage some other companies to not use DRM, equally it might encourage other companies to be extremely restrictive in allowing the BBC to put their media online and isolate the BBC from its viewers (shareholders, license payers, supporters - call them what you will).

You are proposing an argument against the commonly held falacies that Flash and DRM can secure the media and allow it to be resold multiple times. I'm sure the BBC, who have made statements about open formats previously support this, however, making a stance that could damage the institution because the argument against DRM is not been made successfully to those using it is not a reason for the BBC to take the risk and annoy its viewers.

And that works for the license payers who just want to watch content how? By limiting what they can access? Nice way to sink your service and send all your customers to Netflix.

Couldn't they argue that there was self interest involved rather than a fair statement of fact. If you look at old ground and consider the Microsoft litigation regards code being stolen and Novell's (then) indemnity stance against litigation by Microsoft or others on behalf of their paid customers, could it be argued that Novell were using these to safeguard code they owned?

Hmmm - that diary sounds like an interesting account. I'd read commentary from the board who were asked to advise on its use and the technical discussions prior to testing and had heard about the emporer's intervention, however, hadn't heard about the reason for the lack of response.

It doesn't prevent the fact that dropping the bomb and killing so many people - most of whom were not soldiers, at once is pretty horrific. The question becomes simply whether it did prevent long term deaths. ...and whether it caused Godzilla of course?

My biggest concern is that on the back of this there is Novell's takeover by Attachmate (funded in part by the sell off of patents). Who has them now...?

And mostly shipped the waste to countries that will store it and charge you an obscene amount of money for the duration of its half lives...

...like the UK for example.

Still the sound of crickets from the Imperial Palace.

Perhaps that should be the sound of disbelief and complete and utter shock - how many of our people have they killed?!!!?!

Have you actually looked at some of the Open Source desktops recently? KDE is now a fantastic desktop which takes the symantic desktop concept forward better than any other (including OSX and Win) and some of the others are very good too in other ways. To be honest, even Gnome 3 isn't terrible now, it's pretty stable but its just too limiting to be a real desktop from what it used to be in Gnome 2, however, compare it with the tablet desktops, are they limiting? Yes they are.

The problem with G3 is stopped trying to be the best desktop and tried to be a rewrite of some bits of G2, it tried to be a more like a tablet desktop where it led who it should be used rather than lettiing users drive it and while its not failing completely at both, the market has moved on and there are better alternatives out there.

What Gnome needs to do is recognise they aren't the best, refocus on what they need to do to make it the best (and some might be simple usagbility tweaks, some might be new ideas and ways of using it, some might be focussing on a specific market), be clear with people that it will be 6 months or a year before their desktop is near what it needs to be.

I actually think the Linux desktop(s) are now stronger than they have ever been - but also more fragmented.

Some of the reason for this with open source projects is that they come out of a user's desire to do things and fill an niche they see so the teams building the solutions believe they know and understand the end users (they are them). Many of the projects are actually started by gifted but none professional programmers.

It doesn't mean that they can't lose touch with the user base or that the project teams cannot become overly arrogant but I appreciate where they are sometimes coming from or where they can be hostile to complaints. We shouldn't forget that the people doing open source development are often doing it as volunteers. The usual response I give to someone who criticises what I've spent a lot of my time and effort doing for nothing is - if you think you can do better go away and do it yourself or instead of complaining try helping.

Not to mention their access to porn...

I think this is quite straightforward. A company can be responsible for the interfaces that are provided to internal data to none-company devices and the data on company devices. Outside of that the responsibility stops with the end user (employee/customer/guest/consultant/whoever) and the company's usage policies should mirror this and breach of these constitutes breach of contract and therefore liability for damages.

Which is really good for quick docs but gets painful at 20 - 30 GB of images in the docs...

All I can give is the benefit of being in similar situations myself.

My first point of call has been to think about the systems you are working on and work out the commonalities. From there I've start to standardise them into documented systems that are version controlled - your wiki is a fine start to this but I've previously found the same issues you have - fragmentation based on the amount of documentation. This approach doesn't prevent you having lots of differences but does help you to keep track of the commonalities. For example:
1) Systems that run X Operating System you keep to a specific patch level - document it and on all different versions you currently have work towards standardising them to your specific system versions.
2) Systems that run X Database System or other systems need Y differences to the build. These start to form a version numbered build of your platforms.
3) Specific application installs.

To be honest, you've started a big project and will probably take some time but in my experience there are not tools to specifically help with this - ITIL based servicedesks, even with change/cmdb capabilities are not good bases for documentation and I've investigated 7 different ones so far including market leaders. However the approach I've highlighted above I'd say is the start down a CMDB route.