Agreed. Way to screw your business up good and proper. I'm sure Kaspersky is still effective antivirus, but I sure as hell won't be evaluating it now. Remarkable how few corporate antivirus programs combine not creepy, effective, and reasonably resource-friendly. Now I'm down to F-Prot, Sophos, ESET and Avira. Clam's not bad (I use it at home and on mailservers) but I need something with realtime scanning, backed by a company that's been doing it for a few years.

I am, I specify my company's antivirus solution. Kaspersky got crossed off my list to replace the McAfee crap we're dumping. I think I'm probably going to choose F-Prot, it's a highly competent product and I think my government screwed over the lovely little country of Iceland unnecessarily last year: I'd like to make some kind of amends for that.

The performance is an order of magnitude or five better? Honestly, unless you're on something with REALLY high latency, even raw, unmassaged X is frequently better than VNC performance-wise. NX however is hands-down the best performing remote display protocol I've seen. Decently performing (very usable for basic office tasks) full modern desktops when the link has 400ms+ latency and 10kbps bandwidth. It knocks ICA and RDP into a cocked hat.

Thus speaks someone who apparently has never been responsible for the email systems for a small company without a full-time IT department or its own rack. Who cares if the government or the hosting provider reads my email? What are they going to do with it? It's only competitors and casual snoopers that need to be worried about, and the risk for them is the same for hosted email as it is for in-house email given that the in-house email solution is going to have to be exposed to the internet anyway. In what real tangible way is the information security worse with a hosted solution, assuming the hosting provider is competent? In house email is going to take a lot more looking after though, and potentially a lot more infrastructure (servers, decent internet connection, reliable power) than the average small business has or can afford. This is assuming there is anyone in-house who has the skills to look after an email server, which in a lot of small businesses there isn't.

If you're large and important enough that foreign governments are going to be snooping on you and giving your data to their local competitors (think Airbus/Boeing) then sure, you want to be running your own email system. Or if you're a technical business in a highly competitive market. That's maybe 10% of all businesses though. The other 90% don't need the hassle.

What the NTSB doesn't normally do is report unsubstantiated rumor to newspapers about investigations they have no direct jurisdiction over. While their job is certainly to get to the truth of why a plane crashed, in the absence of good evidence they can spin their version whichever way they choose. Unsurprisingly they have chosen to tell the story in a way that is detrimental to the design philosophy of the A330, just as European investigators would tend to blame Boeing if a 767 crashed and no reliable evidence was available as to why it crashed. Being dedicated to the pursuit of truth and being political are not at all mutually exclusive you know.

I think you mean you can make it work with normal quality but you won't get linear scaling of performance as the number of processors increases... For prerecorded material you could do a first pass finding keyframes then encode keyframe-to-keyframe sections on different processors, which will probably scale much better as the processor's L2 cache will be useful.

Sure, there is genuinely a problem on the Linux desktop and that problem is that there are two major toolkits, two major desktops, two looks and feels (despite the KDE/Qt community's attempts to unify them, note that the GTK/GNOME community have done absolutely NOTHING in this regard). However, this problem is ENTIRELY the making of the GNOME community, who came into existence purely as a reaction to KDE and who frankly have been the fly in the ointment ever since. I appreciate their commitment to choice and the (now irrelevant) commitment to the Free Software Ideals but anyone with half a brain has been able to see for about a decade now that the division this has created has made the Linux desktop as a whole suffer overall enormously. To then see someone choose GTK as their toolkit (for a C++ app no less!) and then complain that there is no standardisation is so rich as to make me feel unwell. It's your fault in the first place, and now you are perpetutating it. Grow up, stop whinging, and next time don't make a bum choice and then whinge about it as if it was somehow not your fault.

Which is one of the many reasons I use KDE. Startup speed (KDE 4.2 vs. GNOME 2.26) is about the same on my Ubuntu jaunty box (about 15 seconds from login), but once the DE is booted, KDE apps are literally several times faster to start than the equivalent GNOME apps. e.g. Amarok starts in 2 seconds, while Rhythmbox (which is throughly inferior anyway) takes about 7. Konqueror starts in another couple of seconds, Arora also takes about 2 seconds, Firefox takes about 8 or 9. Once upon a time it used to be that GTK/GNOME apps started up faster, I don't know how they've buggered that up.

On my eee 1000 (with its slow pair of SSDs) I found that while CFQ gave the best average throughput, the noop IO scheduler gave me the best disk latencies and the best interactive performance, which IMHO is much more important on a netbook than raw throughput. I think the issue is that the netbook SSDs have such slow write speeds (and no write cache on the SSD) that any long sequential write freezes all other IO for obviously noticeable periods of time. All of the 'intelligent' IO schedulers in Linux reorder IO requests so that writes happen in one long sequential block if possible to avoid seeking, which is the right strategy for traditional Winchester disks and probably even SSDs with a decent amount of write cache, but wrong for simple, slow SSDs. CFQ isn't too bad as it tries to be fair to different processes asking for simultaneous IO so there aren't too many very long writes, but the anticipatory and deadline schedulers are really painful on my eee.

I'd just like to echo what a few other posters have suggested: stick with AD for now and migrate to Samba4 when it matures.

While you can certainly hook a Windows network up to OpenLDAP, FDS, or $OTHER_DIRECTORY_SERVER, you will end up spending far more time and effort (and hence money) than you save when you try and reimplement all the additional management functionality that is built in, in particular Group Policy. If you decide to skip the Group Policy functionality, you will lose all your hair, acquire several ulcers and otherwise age very quickly as your students end up with the run of the network.

Further, as long as your AD controllers (and you should have at least two for reliability, if you only have two physical servers to play with then virtualise them with Xen or ESXi, run an AD controller on each and then any other VMs you care as well) are ONLY AD controllers then you should find that they are relatively stable. AD has numerous flaws but setup right, it mostly just works, and is the key ingredient to making Windows clients behave sensibly.

The Novell directory stuff works well and retains the management functionality (and gives you some more too) but it still isn't a drop-in replacement and is rather expensive.

Samba4 will be a great drop-in replacement for AD but it's still some way away from being properly production-ready.

I live and work in South Manchester and I've setup and looked after a number of similar heterogeneous networks (with various authentication mechanisms) over the past few years. For a school I'm also happy to do a bit of consulting pro bono. Email me if you're interested: marmarama@gmail.com

This is just off the top of my head and it's been a while since I had to deal with this, so please don't lynch me if this isn't spot on.

The bug is in the file open dialog, which doesn't respect Group Policy settings for the 'Common File Open Dialog' because the Office team decided to reimplement the dialog.

The upshot of which is that you can right-click on files in the dialog and you always get the full range of options, including being able to run executables. IIRC it was fixed in Office 2003 with a separate set of Group Policy settings for the Office version of the dialog.

Of course, if you're implementing Group Policy properly, you should also be using a software restriction policy that will prevent Windows from running any executables that you haven't approved...