The Year Of Linux On The Desktop

 Computing, Linux  No Responses »
Aug 272017
 

Every so often, somebody (or organisation) proclaims that this year is the year of Linux on the desktop. Given the number of times this has occurred, you would have thought that the Cassandras of the Linux world would stop trying to predict it. In fact I am not entirely sure what it is supposed to be – everyone using Linux on the desktop, or just some? And if it is just some people, how many?

It is essentially nonsense – if you use Linux on the desktop, every year is the year of Linux on the desktop; and if you do not, it isn’t.

Assuming you are someone who has more than two brain cells to rub together and are prepared to do some learning, it is perfectly possible to run Linux on the desktop. You can do pretty much everything with Linux that you can do with Windows. In fact the one area that Linux is traditionally weak – upgrading firmware of third party devices (such as media players, wireless mice – is beginning to change with LVMS and fwupd.

To give an example, I was recently upgrading some Logitech wireless mice to eliminate a serious security flaw, and I tried with Windows, OSX, and finally Linux. Both the Windows and OSX methods failed, whereas the Linux method just worked.

In fact even if the Windows method had worked, it would have been a lot more complex. I had to download the Logitech software (admittedly this step would probably be unnecessary if I was used to using the wireless mouse under Windows), know that a firmware upgrade was necessary, download the firmware upgrade, and finally load it into the upgrade tool.

Under Linux? Assuming I had been using some gooey tool like GNOME Software, it would have notified me that an upgrade was available and after a request would have upgraded it for me. I (of course) chose to do it the geeky way from the command-line, but even so running :-

# fwupmgr refresh
# fwupmgr update

… is a great deal simpler than the Windows way. And that is before you consider that with Windows, you need to download a firmware update tool for every device whereas the Linux way it is just one tool.

Of course in practice, the Linux method only works for a handful of devices – of the innumerable Linux machines I run only one has available updates for the desktop computer’s firmware (the Dell at work), and of the peripheral (or not so peripheral) devices only a tiny handful can be upgraded today.

But it is not inconceivable that in the not too distant future, the sensible way to upgrade the firmware of various devices will be to install Linux, and let it do it for you. Particularly if device manufacturers realise that by adopting Linux as the firmware upgrade delivery method, they can save time and effort.

“But I know Windows” – actually you know Windows 7, or Windows XP, or Windows 10; each of which is very different from each other. And whilst Linux has even more variability at first glance, there is actually more commonality between different versions of Linux. Or in other words, the effort of learning Linux in the first place is rewarded by less of a need to completely re-educate yourself every time you upgrade.

This is not intended as encouragement for you to switch to Linux (although if you are involved in IT you should at least be familiar with Linux), but intended as a criticism of the concept of a year of the Linux desktop. It isn’t useful, and what is worse it leads to the false impression of failure – if everyone is not using Linux on the desktop, then Linux has failed.

Linux on the desktop has not failed because I use it on the desktop.

Is AMD’s Threadripper The Next Big Thing?

 Computing  No Responses »
Aug 262017
 

No. The title is just click-bait (which won’t accomplish much).

AMD Ryzen was interesting because it restored AMD’s competitiveness as compared to Intel for the non-enthusiast processor for desktops and laptops. Whereas AMD’s Epyc was interesting because it restored AMD’s competitiveness in the data centre. Both are good things because Intel has been rather slow at improving their processor over the last few years – enough that people are taking a serious look at a non-compatible architecture (the ARM which is found in your smartphone) in the data centre.

Threadripper itself is of interest to a relatively small number of people – those after a workstation-class processor to handle highly threaded workloads. A market that was previous catered to by the Xeon processor, so although Threadripper looks expensive, it is in fact pretty cheap in comparison to Xeon processors. So ‘scientific’ workstations should become cheaper.

And the significant advantage they have with I/O (64 PCIe lanes as opposed to a maximum of 44 for the X299 platform would be useful for certain jobs. Such as medium-sized storage servers with lots of NVMe caching, or graphics-heavy display servers (room sized virtual reality?).

But for gamers? Not so much. Almost no games use lots of threads (although it would be useful to change this), so the main use the extra power of Threadripper will only get used by other things that gamers do. Perhaps game streaming and/or using the unused power to run virtualised storage servers.

Ubuntu, Compiling Awesome, and Messing With Lua

 Computing, Linux, Working Notes  No Responses »
May 202017
 

I just love messing around with run-time languages that I know relatively little about (and if your sarcasm detector isn’t flashing red about now, take it out and give it a good talking to).

The problem detailed here is something that you are unlikely to encounter unless you get into weird stuff like running an odd-ball window manager, aren’t content with the version of said window manager distributed with your Linux distribution, and are used to re-compiling things from scratch.

It all started when I upgraded Ubuntu on my work machine (to Zesty Zapus). The window manager version was upgraded from 3.5 to 4.0, which broke on my configuration file (3.5); not a big problem I thought, as I had already upgraded my window manager at home to 4.1 and reconfigured the configuration file. I copied the updated configuration file from home into place.

And it failed. Apparently I use 4.1-isms within the file. As I was not happy about tinkering with the file to downgrade it (in a language I know relatively little about), I decided to re-compile Awesome 4.1 instead.

Which failed with a weird error :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: [string "return require('lgi.version')"]:1: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file '/usr/local/share/lua/5.3/lgi/version.lua'
	no file '/usr/local/share/lua/5.2/lgi/version.lua'
	no file '/usr/local/share/lua/5.3/lgi/version/init.lua'
	no file '/usr/local/share/lua/5.2/lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version/init.lua'
	no file '/usr/share/lua/5.3/lgi/version.lua'
	no file '/usr/share/lua/5.3/lgi/version/init.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi/version.so'
	no file '/usr/lib/lua/5.3/lgi/version.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi/version.so'
	no file '/usr/local/lib/lua/5.3/lgi.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi.so'
	no file '/usr/lib/lua/5.3/lgi.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi.so'

Which had me stumped for a while, and it turns out that DuckDuckGo didn’t have an obvious fix (one of the reasons for writing this).

Eventually I figured out that awesome was not finding the LGI module (I can be slow at times) which was odd because it was definitely installed. However it turns out that it was installed in /usr/share/lua/5.2/lgi. So despite having lua 5.3 installed, extra lua modules can only be seen if you have lua 5.2 installed?

The “fix” for this was to create an environment variable telling LUA to search for files in rather more places before starting Awesome :-

export LUA_PATH="/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.2/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/share/lua/5.2/?/init.lua;./?.lua;./?/init.lua"

This was created by running lua from the command line and running print(package.path) to display the default setting, and adding the 5.2 equivalent for many elements.

As to whether it works or not, well I cannot be sure (I’m not going into work on a weekend just to check if the window manager fires up), but Awesome itself seems happy with the result :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.1

So it can find LGI, but whether it can do anything useful with it remains to be seen!

WannaCrypt Makes Other Malware Authors WannaCry

 Computing, Security  No Responses »
May 172017
 

It may not be very funny, but the funny thing about WannaCrypt is that it is somewhat of a failure! Unless the authors are spectacularly stupid (not entirely impossible incidentally), they have no way to recover their ill-gotten gains. The pile of looted bitcoins they have acquired is fully visible, so any attempt to use those coins will almost certainly result in them being tracked down – they have attracted too much attention.

Which is another aspect of the WannCrypt malware – it has highlighted the vulnerability (MS17-010) and caused a huge vulnerability hunt. Which is causing those who wrote other malware (such as Adylkuzz) to gnash their teeth, because otherwise their malware would have quietly worked away in the background. The malware authors behind Adylkuzz have probably made more money than the WannaCrypt malware authors … and may well get away with their loot too.

Which is why other malware authors “wannacry” – the attention that WannaCrypt has gotten has ruined MS17-010 for them.

When Windows Update Lies

 Computing, Security  No Responses »
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.

 Older Entries  Newer Entries