May 172017

It seems rather strange when you discover it, but Windows Update sometimes lies about what updates have been installed. I am not sure how often this happens, but it does happen from time to time. Which with WannaCrypt rampaging around is somewhat unfortunate.

What seems to happen is that Windows Update gets confused about what patches it has installed – it’s internal database gets corrupt. One possible fix for this is to remove the database :-

net stop wuauserv
cd %systemroot%
ren SoftwareDistribution SoftwareDistribution.old
net start wuauserv
rd /s/q SoftwareDistribution.old

When using Windows 10, you may well have to start (net start wuauserv) Windows Update services before stopping them. Once you have removed the directory, the next time you run Windows Update in the gooey, it will spend some time rebuilding it’s database and hopefully will then pick up the missing updates. No promises but this worked on at least one server that had unacknowledged missing patches.

Of course without a proper vulnerability scanner it may be tricky to determine when Windows is lying about being fully patched. The best bet is to assume it is lying whenever something like WannaCrypt comes along.

The other possibility is to look into something like Autopatcher which is intended for offline updates – you can download the Microsoft updates and use the tool to patch Windows computers from the downloads.

Apr 302017

Despite how long I have been running Windows in virtual machines (as far back as Vmware Workstation 1.0), I have never gotten around to looking at the virtio network interface – except for naïvely turning it on once, finding it didn’t work, and turning it off – so I decided to have a look at it. I was prompted to do this by a suggestion that emulating the NIC hardware as opposed to simply using a virtual communications channel to the host would hurt network performance. Good job I chose a long weekend because I ran into a few issues :-

  • Getting appropriate test tools took a while because most of the tools I know of are very old; I ended up using iperf2 on both the Linux main host and the Windows 10 guest (within the “Windows
  • The “stable” virtio drivers (also called “NetKVM”) drivers didn’t work. Specifically they could send packets but not receive them (judging from the DORA conversation that was more of a DODO). I installed the “latest” drivers from Note to late readers: this was as of 2017-04-30; different versions may offer different results.
  • Upgrading my ancient Debian Jessie kernel to 4.9 on the off-chance it was a kernel bug turned into a bit of an exercise what with ZFS disappearing after the upgrade, and sorting out the package dependencies to get it re-installed was “interesting” (for small values of course). No data loss though.

I ran two tests :-

  1. sudo nping –tcp -p 445 –count 200 –data-len 1280 ${ip of windows guest) – to judge how reliable the network connection was.
  2. On the Linux host: sudo iperf -p 50001 
  3. On the Windows guest (from within the Ubuntu-based environment): sudo iperf -p 50001 -c ${ip of Linux host}
Device nping result iperf result
Windows guest (virtual Intel Pro 1000 MT Desktop 1 lost 416 Mbits/sec
Windows guest (virtio) 0 lost 164 Mbits/sec
CuBox running ARM Linux n/a 425 Mbits/sec

Which is not the result I was expecting. And yes I did repeat the tests a number of times (I’ve cheated and chosen the best numbers for the above table), and no I did not confuse which NIC was configured at the time of the tests nor did I get the tests mixed up. And to those who claim that the use of the Ubuntu environment screwed things up, that appears not to be the case – I repeated the test with a Windows compiled version of iperf with much the same results.

So it seems despite common sense indicating that a NIC “hardware” custom designed for a virtual environment should perform better than an emulation of a hardware NIC, the actual result in this case was the other way around. Except for the nping result which shows the loss of a single packet with the emulated hardware NIC.

Oct 192016

I have just been listening to a Microsoft fanboy on the you tube wittering on about something (not computer related), when he tried to read out a URL. According to him, there are “backslashes” in the URL.

Not in any normal URL. For those who do not know, URLs are web site addresses such as The character that appears after the network protocol (http) – the “/” is formally known as the solidus, and less formally as a slash. The slash that goes the other way is called the backslash (or more formally the reverse solidus).

And who decided that one was a slash (‘/”) and the other a backslash (‘\’)? Although it has been used since the Medieval era, it was probably first called as solidus in the 19th century because of it being used to signify the British shilling. Currently it is the Unicode Consortium who call it a solidus in the international standard for character encoding. If you disagree with them, by all means either convince them they’re wrong or set up a new international standard and get it more widely adopted than Unicode.

Until then, I’ll carry on calling someone who says a backslash looks like – ‘/’, wrong.

Does it matter? In the big scheme of things probably not, but it does make reading out instructions more difficult when either slashes or backslashes appear. After all computers rarely say “Ah! I see what you meant! You meant which is different (and makes sense) to http:\\\“. And as anyone who has ever encountered autocorrect “mistakes” will attest, letting computers decide what you meant is not always the best idea.

And how did the mistake originally occur? To some extent Microsoft is to blame, although I doubt Microsoft ever called the slashes the wrong name.

When Microsoft wrote their first operating system (DOS), they chose to make it semi-compatible with an earlier operating system (CP/M) which used the slash to indicate the use of an option to a command-line command which in turn was inherited from certain early DEC operating systems.

When they came to implementing directories (yes that long ago), they broke with the tradition of stealing ideas from DEC (or we would have ended up with paths like C:[WINDOWS.SYSTEM]FOO.SYS) and instead chose the Unix path separator. But the slash conflicted with option processing on the command-line, so they used the backslash instead – C:\WINDOWS\SYSTEM\FOO.SYS.

Of course people started calling the backslash, a slash, and I’m sure there are many out there who will continue despite being told that they are wrong. Of course when I say they’re wrong, I have the backing of an international group of grapheme experts behind me.


Oct 232013

Crazy experiment time. What happens when you have a disk with 100 partitions? The replacement for the old MBR standard for partitions on PC hardware is slowly being replaced with GUID partitions. The later increased the maximum number of partitions to 128 which is probably far more than anyone needs, but what happens when you have a disk with 100 partitions?

As it happens, I had a spare external drive to play with, so set something up :-

for x in {1..99}     
  parted /dev/sdc mkpart FAT $(($x * 100)) $((x * 100 + 99))
  mkfs -t vfat /dev/sdc${x} 

This took a surprising amount of time to run with two interesting effects :-

  1. The mkfs tool refused to make a filesystem on /dev/sdc16 and /dev/sdc80 as it claimed it would be creating a filesystem on a full disk device. I suspect that this is a bug due to simplistic assumption of what constitutes a full disk device based on minor device numbers (/dev/sdc16 happened to be 0 and /dev/sdc80 happened to be 64). This could probably be solved by using device nodes within /dev/disk/by-${something}/${whatever}.
  2. The Unity Launcher appeared to attempt to populate itself with the new filesystems as they were being created, but very rapidly decided not to bother. This happened several times.

Once the creation process was complete, I reconnected the external drive to my Ubuntu machine, and yes the launcher does contain a ton of hard disk icons. The launcher is still full functional, but having a hundred (or so) devices below the normal icons does make using it a little clumsy.

Fortunately it did not mount all the filesystems automatically – closing that many windows would be very tedious. Mounting them all via a file manager window was pretty tedious, but it worked :-

/dev/sdc56             95M     0   95M   0% /media/mike/8663-39C5
/dev/sdc65             95M     0   95M   0% /media/mike/8673-0919
/dev/sdc71             95M     0   95M   0% /media/mike/873E-FEE7
/dev/sdc72             95M     0   95M   0% /media/mike/8741-47B3
/dev/sdc79             95M     0   95M   0% /media/mike/874D-4B53
/dev/sdc81             95M     0   95M   0% /media/mike/874E-D280
/dev/sdc82             95M     0   95M   0% /media/mike/8752-1ACE
/dev/sdc83             95M     0   95M   0% /media/mike/8754-2562
/dev/sdc84             95M     0   95M   0% /media/mike/8755-D262
/dev/sdc86             95M     0   95M   0% /media/mike/8759-0D82
/dev/sdc87             95M     0   95M   0% /media/mike/875A-E5C5
/dev/sdc89             95M     0   95M   0% /media/mike/875E-035B
/dev/sdc92             95M     0   95M   0% /media/mike/8763-8FB5
/dev/sdc93             95M     0   95M   0% /media/mike/8765-7A2F
/dev/sdc94             95M     0   95M   0% /media/mike/8767-1DBC
/dev/sdc95             95M     0   95M   0% /media/mike/8768-D314
/dev/sdc96             95M     0   95M   0% /media/mike/876A-A46E
/dev/sdc97             95M     0   95M   0% /media/mike/876B-F064
/dev/sdc98             95M     0   95M   0% /media/mike/876D-9D90
/dev/sdc58             95M     0   95M   0% /media/mike/8666-B9AA
/dev/sdc61             94M     0   94M   0% /media/mike/866B-8EFA
/dev/sdc62             95M     0   95M   0% /media/mike/866D-1726
/dev/sdc64             95M     0   95M   0% /media/mike/8671-5EE1
/dev/sdc66             95M     0   95M   0% /media/mike/8736-C2F5
/dev/sdc67             95M     0   95M   0% /media/mike/8737-EE95
/dev/sdc68             95M     0   95M   0% /media/mike/8739-7213
/dev/sdc69             94M     0   94M   0% /media/mike/873B-181F
/dev/sdc70             95M     0   95M   0% /media/mike/873C-E80C
/dev/sdc73             95M     0   95M   0% /media/mike/8743-11E7
/dev/sdc74             95M     0   95M   0% /media/mike/8745-28A8
/dev/sdc75             95M     0   95M   0% /media/mike/8746-CA94
/dev/sdc77             95M     0   95M   0% /media/mike/874A-1D30
/dev/sdc78             95M     0   95M   0% /media/mike/874B-C1C7
/dev/sdc85             95M     0   95M   0% /media/mike/8757-77A0
/dev/sdc88             94M     0   94M   0% /media/mike/875C-6DF9
/dev/sdc90             95M     0   95M   0% /media/mike/8760-8FD5
/dev/sdc91             94M     0   94M   0% /media/mike/8762-01DA
/dev/sdc99             94M     0   94M   0% /media/mike/8770-0F74
/dev/sdc1              93M     0   93M   0% /media/mike/8609-229A
/dev/sdc17             95M     0   95M   0% /media/mike/8621-921D
/dev/sdc21             95M     0   95M   0% /media/mike/8628-8CDB
/dev/sdc22             95M     0   95M   0% /media/mike/862A-2217
/dev/sdc23             94M     0   94M   0% /media/mike/862B-8EF9
/dev/sdc25             95M     0   95M   0% /media/mike/862F-0BE5
/dev/sdc27             95M     0   95M   0% /media/mike/8633-1F9D
/dev/sdc28             95M     0   95M   0% /media/mike/8634-A26F
/dev/sdc34             95M     0   95M   0% /media/mike/863E-14EB
/dev/sdc37             95M     0   95M   0% /media/mike/8643-1F63
/dev/sdc4              95M     0   95M   0% /media/mike/860D-2753
/dev/sdc40             95M     0   95M   0% /media/mike/8647-8E49
/dev/sdc41             95M     0   95M   0% /media/mike/8649-033D
/dev/sdc42             94M     0   94M   0% /media/mike/864A-A12A
/dev/sdc43             95M     0   95M   0% /media/mike/864C-6EEF
/dev/sdc44             95M     0   95M   0% /media/mike/864E-3469
/dev/sdc45             95M     0   95M   0% /media/mike/8650-8796
/dev/sdc46             95M     0   95M   0% /media/mike/8652-64DF
/dev/sdc47             95M     0   95M   0% /media/mike/8653-F743
/dev/sdc48             95M     0   95M   0% /media/mike/8655-B14B
/dev/sdc49             95M     0   95M   0% /media/mike/8657-34FF
/dev/sdc5              95M     0   95M   0% /media/mike/860E-EBD7
/dev/sdc50             94M     0   94M   0% /media/mike/8658-A04A
/dev/sdc51             95M     0   95M   0% /media/mike/865A-D4D3
/dev/sdc52             95M     0   95M   0% /media/mike/865C-33D1
/dev/sdc53             95M     0   95M   0% /media/mike/865D-FA56
/dev/sdc54             95M     0   95M   0% /media/mike/8660-6C95
/dev/sdc55             95M     0   95M   0% /media/mike/8661-D456
/dev/sdc57             95M     0   95M   0% /media/mike/8665-0AFD
/dev/sdc59             95M     0   95M   0% /media/mike/8668-3D53
/dev/sdc6              95M     0   95M   0% /media/mike/8610-F9B0
/dev/sdc60             95M     0   95M   0% /media/mike/866A-0A0E
/dev/sdc63             95M     0   95M   0% /media/mike/866E-F6E7
/dev/sdc76             95M     0   95M   0% /media/mike/8748-8D02
/dev/sdc10             95M     0   95M   0% /media/mike/8616-B29F
/dev/sdc11             95M     0   95M   0% /media/mike/8618-6462
/dev/sdc12             94M     0   94M   0% /media/mike/861A-5208
/dev/sdc13             95M     0   95M   0% /media/mike/861B-BA6E
/dev/sdc14             95M     0   95M   0% /media/mike/861D-5133
/dev/sdc15             95M     0   95M   0% /media/mike/861E-C384
/dev/sdc18             95M     0   95M   0% /media/mike/8623-BFCF
/dev/sdc19             95M     0   95M   0% /media/mike/8625-9D85
/dev/sdc2              95M     0   95M   0% /media/mike/860A-504E
/dev/sdc20             94M     0   94M   0% /media/mike/8627-1391
/dev/sdc24             95M     0   95M   0% /media/mike/862D-457F
/dev/sdc26             95M     0   95M   0% /media/mike/8631-5F8A
/dev/sdc29             95M     0   95M   0% /media/mike/8636-2F58
/dev/sdc3              95M     0   95M   0% /media/mike/860B-8C77
/dev/sdc30             95M     0   95M   0% /media/mike/8637-F726
/dev/sdc31             94M     0   94M   0% /media/mike/8639-6B19
/dev/sdc32             95M     0   95M   0% /media/mike/863A-FBBC
/dev/sdc33             95M     0   95M   0% /media/mike/863C-AE68
/dev/sdc35             95M     0   95M   0% /media/mike/8640-3A10
/dev/sdc36             95M     0   95M   0% /media/mike/8641-93A6
/dev/sdc38             95M     0   95M   0% /media/mike/8644-AFCF
/dev/sdc39             94M     0   94M   0% /media/mike/8646-1BAE
/dev/sdc7              95M     0   95M   0% /media/mike/8612-54E8
/dev/sdc8              95M     0   95M   0% /media/mike/8613-C38C
/dev/sdc9              95M     0   95M   0% /media/mike/8615-3522

Yes I have cut the “interesting” filesystems out of that output.

Windows (7) does deal quite so well with the situation. After rebooting into Windows with the disk plugged in, the login process seemed to take longer than usual (although I don’t boot Windows enough to be sure).

Once logged in, everything seemed fine including the little popup window by the status bar saying it was configuring the plugged in disk drive. However that took longer than expected – after clicking on it for details, it took around 5 minutes to complete. At which point it stuck a red cross by the “Disk Drive” whilst it popped up an Autoplay window for drives E: through Z:. With an offer to format drive T: – so it could at least use the drive that Linux refused (by default) to format.

However except for that little red cross, there was no clear warning that it failed to do anything with nearly 80 partitions. And closing all those popup Autoplay windows was pretty tedious.

OSX (10.9) dealt a little better with the disk; it at least recognised all of the disks, and stuck up little icons for each one. And mounted them all.  However Finder didn’t seem to respond to attempts to unmount the disks … I had to resort to the command-line. Perhaps I wasn’t patient enough.

And the moral of this little crazy experiment? Whilst we can perhaps throw a little mud at Microsoft, the main lesson learnt is that you too can annoy someone using Windows by handing them an external hard disk with 100 partitions. Especially if the information they want is not in the first 20-odd partitions <Evil Grin>

Oh! And just stating the obvious – it’s a good idea to remove the partitions before putting the spare disk away, or you may encounter a nasty surprise later!


Oct 312011

According to a couple of articles on The Register, a couple of manufacturers are getting close to releasing ARM-based servers. The interesting thing is that the latest announcement includes details of a 64-bit version of the ARM processor, which according to some people is a precondition for using the ARM in a server.

It is not really true of course, but a 64-bit ARM will make a small number of tasks possible. It is easy to forget that 32-bit servers (of which there are still quite a few older ones around) did a pretty reasonable job whilst they were in service – there is very little that a 64-bit server can do that a 32-bit server cannot. As a concrete example, a rather elderly SPARC-based server I have access to has 8Gbytes of memory available, is running a 64-bit version of Solaris (it’s hard to find a 32-bit version of Solaris for SPARC), but of the 170 processes it is running, none occupies more than 256Mbytes of memory; by coincidence the size of processes is also no more than 256Mb.

The more important development is the introduction of virtualisation support.

The thing is that people – especially those used to the x86 world – tend to over-emphasise the importance of 64-bits. It is important as some applications do require more than 4Gbytes of memory to support – in particular applications such as large Oracle (or other DBMS) installations. But the overwhelming majority of applications actually suffer a performance penalty if re-compiled to run as 64-bit applications.

The simple fact is that if an application is perfectly happy to run as a 32-bit application with a “limited” memory space and smaller integers, it can run faster because there is less data flying around. And indeed as pointed out in the comments section of the article above, it can also use ever so slightly more electricity.

What is overlooked amongst those whose thinking is dominated by the x86 world, is that the x86-64 architecture offers two benefits over the old x86 world – a 64-bit architecture and an improved architecture with many more CPU registered. This allows for 64-bit applications in the x86 world to perform better than their 32-bit counterparts even if the applications wouldn’t normally benefit from running on a 64-bit architecture.

If the people producing operating systems for the new ARM-based servers have any sense, they will quietly create a 64-bit operating system that can transparently run many applications in 32-bit mode. Not exactly a new thing as this is what Solaris has done on 64-bit SPARC based machines for a decade. This will allow those applications that don’t require 64-bit, to gain the performance benefit of running 32-bit, whilst allowing those applications that require 64-bit to run perfectly well.

There is no real downside in running a dual word sized operating system except a minor amount of added complexity for those developers working at the C-language level.

WP Facebook Auto Publish Powered By :

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.