Really, if MS was not MS but a company that was payed to write applications, making this information public should be enough reason not to hire them.
Let me rephrase the explanation: “If you give me a letter and say that this letter is only handed once, I will drop it because… well… because… no reason…”
Following the KB’s logic, if a document expires after 1 second and an application takes more than a second to launch then it should not be able to open the file…
… and it gets better: If the document expires after 10 seconds, you should have 10 seconds to read it. Else the document will be closed…
… and finally: if you save this document to a file, the file should be automatically deleted after it has expired.
Those are not true, but according to MS’s logic, they could be. Perhaps in IE10
Virtualization has a lot of benefits. Especially when you are messing with windows machines. It is far easier to have a template machine and clone it on-demand instead of setting up a new window installation every time or using disk-cloning software.
However, no matter how easy one attempts to make his life, windows will react on that. Here is what is an unintentional (I hope so) effect of windows protection and AI:
Assume that you have a virtual machine under XEN and you want to use it as template, so you create a nice image using dd for future use. Now, this machine is up and running for some months.
You then want to create a duplicate of this machine, so you create a new XEN config, a new logical volume and you restore the template image on the logical volume. You then create the domain.
You access the console using vnc and attempt to login. At this point windows ask for activation so you tell them “OK.. activate over the network”. At this point windows detect an IP address conflict (the other machine is running). Network activation fails because windows have disabled the network card and you can’t login to fix this because you need to activate them first… That’s obstacle #1
In order to fix the problem you shutdown the original machine to avoid having a conflict. Then you switch to the clone and attempt to re-activate them… Since the network interface is disabled (or the address is not applied) activation fails again… That’s obstacle #2
Then you say “OK… I’l perform a reboot”, only to find out that “shutdown” is grayed by default for windows 2003 server… That’s obstacle #3
Finally you shutdown the machine the “hard way” and restart it. Then you attempt to login again and windows ask you “why did the machine shutdown unexpectedly?”… That’s the irony…
While performing some tests with a congested 10Mbps link, a strange thing happened: The link was congested only on one direction and both endpoint queues were RED queues. Based on the parameters and the queue size, the delay between those two links should be something near 170ms. However, the delay was much larger: >300ms (!).
The “problem” was the ring-buffer of the underlying driver (e1000). This one used a buffer of 128 packets which when added to the average 150 packets in the queue, resulted in >300ms delay.
You can see this buffer by running:
#ethtool -g eth0
And you can modify this buffer by running:
#ethtool -G eth0 tx 80
This is the transmit buffer which (when filled) adds to the delay of the local queue.
Of course, in normal use, this buffer is a good thing as it will allow to get higher transfer rates easier (from the POV of the operating system). But when making experiments, this little thing gets in the way.
Another thing is that there seems to be a minimum value for this number. For example, on this card:
Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller
the minimum value is 80 (using e1000 driver from kernel 2.6.32)
So beware and don’t loose a week looking for this thing like I did.
NOTE: This is not related to the transmit queue length that is used on the interface, as shown by:
# ifconfig eth0
# ip link show eth0
For a long time ago, a computer connected to the Internet had an RV770 ATI card and used to use the proprietary fglrx driver. Yes… That was my pc…
Then the latest fglrx (10.2) wasn’t compatible with the latest kernel (2.6.33) and that kernel supported Kernel Mode Setting (KMS) using the radeon driver. Debian also started to have appropriate libdrm and Xorg (+ driver).
So I switched to radeon/KMS driver… At first everything was not working and I blamed the radeon driver. However, as it was proved, even after uninstalling the fglrx driver it kept causing me problems. A couple of files were left behind and there was at least one file left diverted to the fglrx’s one. To fix this problem one needs to examine diversions (dpkg-divert –list), use debsusm (e.g. debsums -s libgl1-mesa-glx) and reinstall the packages with checksum problems.
Finally, after switching to radeon/KMS the following things changed:
The used memory after startup reduced from about 2.5-3GB to less than 500MB (!!!!). I’m not talking about card’s mapped memory. I’m talking about system’s memory.
Everything runs a lot faster. It looks like system latency is greatly reduced. There are two kind of improvements: (a) KDE’s desktop effects are smoother and (b) it looks like the latency is reduced. Somehow the effects seem to run faster because there is less delay.
I stopped getting crashes of plasma when logging-in.
KDE’s effects stopped being disabled every now and then.
Tearing disappeared (!).
Compositing effects seem to use less CPU.
Some sound-card issues disappeared. Every now and then the sound was muted after system startup, but not any more.
So yeah… I really suggest that you switch to radeon/KMS if you’re using the fglrx driver. It sucks.
BTW, I also tested that to a laptop with an older ATI card and it had most of the above improvements as well. A colleague of mine also switched to opensource driver and show the exact same, dramatic reduce of memory usage.
Cisco switches support CDP and use it to help us in a number of ways. One of them is to detect native VLAN mismatch between two connected ports. For 99% of the time this is a “good thing to do” ™ but there are some corner cases where this is not what you want.
For example, if you have a switch that is connected with another switch and their connected ports are configured as access ports (and not trunk ports) then this message doesn’t make much sense.
Well… it does…
Cisco switches also support VTP which eases the VLAN management task. For VTP to work, switches that are under the same “local network” are also under the same “VTP domain”. A VTP domain logically groups switches.
Now, here is the problem: Two switches connected using access mode that are in the same VTP domain should share the same VLAN configuration, even if they are configured as transparent.
What to do: To bypass this problem you have to change the vtp domain on those switches so that it doesn’t match. If you haven’t changed that already, they most probably are not in any VTP domain at all or they are in the same VTP domain.
The solution:
Configure at least one of the two switches to be in transparent mode. You may not want that, but if you don’t know what this means then just do it:
Switch(config)# vtp mode transparent
Change the VTP domain of that switch:
Switch(config)# vtp domain a_unique_name
(you may want to use the hostname)
… and this annoying message:
Oct 27 12:16:29.352 EET: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet2/6 (2), with sw-el0 GigabitEthernet0/8 (1).
For a long time now i see my CPU usage rising and falling back every some seconds. This is very annoying and it really slows things down. Finally, I found (to some extend) what causes this problem. Using “udevadm monitor” I show that the CPU was rising whenever a uid-add event was created by the kernel:
I also found that the program that causes the CPU load is “hal-acl-tool” but not directly. In fact, hal-acl-tool wasn’t consuming a lot of CPU and top wasn’t showing anything. With process accounting I found that there are 1000s of invocations of /usr/lib/policykit/polkit-read-auth-helper:
$ lastcomm |grep polkit-read-aut | wc -l
61161
in a couple of minutes (!). This seems to be a bug that troubles other people too.
Finaly, I concluded that the problem is not related to uid-add events but to session creation. The problem is caused by console kit and its pam hook: pam_ck_connector.so. For newer debian versions (read: testing) you can disable this by running (as root) pam-auth-update and deselecting the “ConsoleKit Session Management”.
WARNING: I’m not aware of the drawbacks of disabling “ConsoleKit Session Management”, so do this at your own risk.
To my knowledge, this happens because $v is kept as a reference to the last element when the first foreach is finished. Then, when the second foreach is ran, some assignments are performed to $v, destroying its last element.
For KDE 4 and python there can be a hard to debug problem with KAutostart usage.
Suppose you have a window class
class MyWindow(KDialig, Ui_Dialog):
def __init__(self):
self.kas = KAutostart('myapp')
self.kas.setAutostarts(True)
You may find that the setAutostarts() doesn’t actually work. This is because MyWindow references kas and kas references MyWindow (as the parent object) (or the application - I’m not sure). The problem is that KAutostart() stores the information when it is deleted (in it’s destructor) and since it is never deleted it won’t store anything.
You need to understand that the destructors won’t be called even when the program exits, because of the circular reference.
To solve the problem call:
self.kas=None
at some point.
Have a look here for more on python and its destructors.