amongst other things...
If Xen is your thing, Cory von Wallenstein's relatively recent article on IPv6, Ipv6, and ARP on Xen might be of interest to you.
I'm unsure if his patches have been merged into the main Xen source, but it's still an interesting read and useful if you're wanting to secure Xen domU's, or experiment with IPv6.
...the stupid are everywhere.
It's an old joke from the days of Red Dwarf, and I'm sure I've used it before many times. However, reading utter uninformed crap from a school teacher, regarding free and open source software warrants the usage again, in my mind.
I can understand that some one has a difference in opinion and I can understand the right to complain. What I don't understand is why you'd write such a thing if you appear to know absolutely nothing about the subject†.
The thing I most love about the article is that it ends in such a childish way. The 9 year old nerd in me loves that.
† Scrub that. All you need to do is take a look at the BBC's open comments to see why.
I tend to buy geek and nerd related books for two main reasons: 1, because I don't like taking my laptop to the bog and reading, and 2, because there's nothing really like a book. There are a few others, which orientate around being able to read a book away from the computer or laptop, relaxing on the sofa, or in the garden, but they aren't as important to me - but mostly only because I do my best thinking in the bathroom.
Anyway. 'Running Xen' was on the few books I had delivered a few days ago. To clarify this is a book on running Xen, the open source hypervisor. Like all books I was hoping for something that delivered a little bit more than the man pages and online docs. Sadly this wasn't really the case.
Now I'm not saying that 'Running Xen' is a bad book. It's not. It's just missing that "something more", that "je ne sais quoi" (I cannot believe I've just typed that and not removed it). If you're going to somewhere without man pages or online docs, then it's an invaluable reference.
Worth £21 (it's current cost on Amazon)? Without reading more books on Xen, I honestly don't know, but despite feeling as I do, I am glad that I've got it.
Mostly because I've had some awesome ideas, whilst on the bog with it.
...redirected App data directories, and causes a crash (Visual C++ Runtime error). Unfortunately after updating one or two of our customers at work it appeared that a few user accounts still had a redirected app data directory, presumably because they weren't around when it was removed.
Thankfully fixing it is pretty easy (although potentially time consuming depending on your setup), if the redirection policy isn't active and is simply a case of changing the relevant entry under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders, and then logging off and back on, and migrating the redirected files back into the local profile directory.
As far as I'm aware the affected products are;
If you're not using redirected app data directories any more then this is obviously a handy fix. If for whatever reason you're still using redirected directories and not roaming profiles, then you're screwed as it appears that Adobe aren't planning on fixing this.
Things like this really piss me off and just make me feel like the majority of my work is working around bug, flaws or oversights and is just why I prefer open solutions and platforms; at least I'd have the possibility of trying to fix it in-house.
This one really had us at work and really threw us massively. Imagine a customer who has recently had a number of non trivial modifications to their network. Now imagine several users, whom have Outlook over HTTP RPC (Outlook Anywhere) configured and enabled for slow networks only, and get asked for authentication when accessing a handful calendars. On the same site as the servers (i.e. on the fast network). Disabling Outlook over HTTP RPC completely, or enabling it for slow and fast networks, and the problem would not occur. With no useful logs what so ever.
The main problem was that so much stuff had changed it was difficult to know where to start, and even harder with nothing useful being logged. It wasn't hitting the proxy server, which had recently had authentication forcefully enabled, it wasn't the IIS and Exchange box.
Turns out that the affected calendars that people were trying to view had recently had their mailbox moved from one storage group, to another, and we were obsessed with it being something else to the point that we'd dismissed this without looking into it. Without HTTP RPC enabled redirection happened without trouble, but with it on it required authentication. But the weird thing was that you could actually see the calendar if you selected Open other user's mailbox, rather than using the "shortcut" (i.e. tickbox) that had already been added in the calendar view.
Simple solution - remove and readd the affected calendars. Our best guess is that this is stored with various pointers or references to not only the mailbox, but also the storage group. After all, it would make sense from a performance point of view if you didn't have to look it up each time.
The moral for me personally, since I'd taken quite a lot of this problem on, is to never forget Occam's Razor. I might actually get a representation of that tattoo'ed on my body, whenever I get around to that part of life again.
