On one of my computers, I have Windows Vista. I mostly use that computer for linux, but I do occasionally use Windows. For anti-virus, I have MSE (Microsoft Security Essentials).
At present, the computer is telling me that the virus tables are 6 days old.
Although I would prefer to use that computer with linux, on Wednesday, I left it running Windows for around 12 hours. It failed to update the AV definitions. On Thursday, I left it running Windows for 14 hours. Again, it failed to update the AV definitions. On Friday, I left it running Windows for 16 hours. And, again, it failed to update the AV definitions. Today (it is still Saturday local time), it has been running Windows for over 10 hours, and has failed to update the AV definitions.
On Wednesday, I also booted my laptop to Windows. I had not used the laptop for several days, so the AV definitions were three days old. It updated after around 3 hours. But the Vista system still has not updated.
This is the third consecutive month when I have had problems with updating MSE, at around the time of patch Tuesday. The previous two months, I attempted to manually update. On the manual update, it did a search for virus updates, then seemed to hang there forever not actually downloading. It did eventually update, after repeating this for two days. This month, I decided to allow it to update without manual intervention, with the results described above.
It seems pretty obvious that, recently, Microsoft has worsened the priority for updates to Windows 7 and to Vista. The priority worsening is greater for Vista than for Windows 7. It affects monthly patches as well as MSE virus table updates.
The message to malware producers is loud and clear. Malware producers should distribute their malware on patch Tuesday, and Microsoft will give them a free run for several days.
I described my experience with installing kubuntu-16.04 in a previous post. Today, I’ll comment on the installed system.
Kubuntu 16.04 is based on Plasma 5. So I’ll first comment on Plasma 5, and then on how kubuntu has implemented it.
I have been seeing a steady improvement in Plasma 5, which I am using on my normal desktop (with opensuse 42.1), as well as on the kubuntu system that I am reviewing. There were some rough edges at the initial release, but by now it is reasonably usable.
Ubuntu 16.04, in several different varieties, came out last week. So I decided to give the kubuntu variant a try. I planned to install in an existing LVM. I knew, from previous experience, that this could be tricky. And, to make it more tricky, I wanted “/boot” to be inside that encrypted LVM.
It didn’t quite work out. I am successfully booting it using the grub2-efi from opensuse. I was unable to get the grub-efi from kubuntu to work.
I planned to install this to replace an experimental Tumbleweed. I had originally set that up a year ago, to test using opensuse with “/boot” part of the encrypted LVM. That test is now well past, and the opensuse bugs have been fixed. So that disk space was free for kubuntu.
I’ve been doing an install each month, mostly to test for problems with the installer. For this month, I download snapshot 20160412. There have been more snapshots since then, but this was the one that I installed yesterday.
The live rescue CD
I also downloaded the live rescue CD at the same time. I must have started the download too soon after publication. This was the slowest download that I have done. Normally, the iso for a rescue CD downloads in a few minutes. For this download, “aria2c” was giving me an estimated download time of around 58 hours and worse. The download site was obviously busy and no mirrors were yet available.
The slow download continued for a while. Then it gave me an error indicating that the download had failed.
In my previous post, I indicated that I would give my own view on “btrfs”. So that’s what this post is about.
Short version — I will continue to use “ext4” in future installs.
Note that this a personal view, not a recommendation. My own choice depends on how I use computers and my practices for backup, recovery, etc. Your practices are likely different. Much of this post will be about my considerations in deciding against “btrfs” for my own use.
What is “btrfs”?
“Btrfs” is a file system for linux. It is based on a b-tree data structure (often used in databases). You can think of the file system directory as an index into that database. I’ll give only a quick summary. You can find a more detailed summary in Wikipedia, or in the sources that linked there.
Thus far, I have been mainly using “ext4” as a file system, and avoiding “btrfs”. But there is one exception. I have “btrfs” on an opensuse Tumbleweed install. This was mostly to get some experience with “btrfs”.
I’ll give my overall opinion, based on that experience, in another post in the next few days.
I have not actually needed to rescue my “btrfs” system. But it is sometimes useful to be able to access it from a different partition. And it can be useful to know how to rescue, just in case.
This month’s install was interesting.
My original plan was to install from the KDE live iso. So I downloaded “openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20160307-Media.iso” and wrote that to a USB. It booted up nicely, and ran well. Among other things, that suggests that the problems with persistent storage on the usb device have been fixed. It created a hybrid partition that was mounted as “ext4” instead of the “btrfs” that had been giving problems with the persistent hybrid partition.
There have been several recent updates to opensuse Leap 42.1. Toward the end of February, there was an update of KDE applications. And earlier this week there was a frameworks updates.
There was, at first, a problem with the update earlier this week. There were two updates that were supposed to be applied at the same time. And somehow they released the frameworks update without also releasing the QT update. That left some folk unable to login to the plasma 5 desktop until they released the complementary QT update.
I’ll note that I was affected by this on one of my computers. But it did not affect my main desktop, because I held off applying the update until all was back in order.
A recent announcement from openSUSE listed new live media (iso files) for Argon and Krypton. Argon is based on Leap 42.1, while Krypton is based on Tumbleweed.
The openSUSE team maintains development repositories, in addition to the standard repos for the distributions. The development repos are where they build new or updated versions of the software for testing prior to adding that software to the standard repos. Both Argon and Krypton include some of these development repos.