Showing posts with label Xubuntu/XFCE. Show all posts
Showing posts with label Xubuntu/XFCE. Show all posts

Wednesday, 26 September 2018

Fun with Buster / KDE over XFCE on Stretch

It's one thing to be able to install an alpha edition of Debian and it's another for it to be usable. But that's part of the whole process for an alpha edition of something.

But because running a Debian alpha is so much of a challenge, I can't do it with a rotated screen like I am attempting to do with my pc4, because I can't guarantee it will be possible to rotate the display with the video configuration of that computer. Therefore the screen has to be in regular landscape orientation and that means I have to find somewhere to have the display that it will fit within the footprint of my desk with the other screens, because at the moment it is vertical to save space.

The other issues with Alpha3 are also significant, and the ones that I have noticed the most so far are in the install process, whereby attempting to install KDE or LXQt as the desktop environment result in a system that will not boot up to that environment. Instead, you get a shell login screen, and you have to type in startx to bring up the desktop environment. XFCE is fine, so my next move will be to try putting KDE over the top of XFCE.

Trying that on serverpc running stretch has turned out to be an issue because, as was my previous experience just putting the breeze logon screen and sddm as the logon manager onto my Debian/XFCE computers (going into XFCE after logon), hibernation has become flaky. Since hibernation is reliable on mainpc running a clean install of KDE on stretch, serverpc's reinstallation from scratch with Debian/KDE is the obvious next move, and fortunately it isn't as time consuming as reinstalling mainpc because serverpc doesn't run a lot of stuff. On the Buster computer this issue won't exist because it won't be expected to hibernate anyhow.

After installing Buster again on pc4, with XFCE as the default desktop environment, I then attempted to install LXQT over the top of it. However, after configuring sddm (the default window manager for LXQt and KDE) as the display manager, the desktop failed to start and I was left with the command shell logon. This is basically a repeat of the issue when installing either KDE or LXQt as the windowing environment during the install. If you type startx then it will start up, apparently in lightdm, which indicates there is some sort of issue with sddm.

At the moment that is what I am left with, but then that is one reason it is an alpha, so I imagine there is probably already work happening to resolve these issues.

serverpc is still having issues after resuming from hibernation, the issues are that one screen fails to load the background and both screens fail to load the panels. So I am going to try setting up a new user profile, fortunately these panels don't have a lot of customisation. bedroompc has had x11vnc put onto it to replace Krfb because the latter can't handle a two homed computer (one with two network interfaces, the wireless and cable) and it picked the wrong interface to bind to so I couldn't remote to it with Remmina. So I have installed the latest version of x11vnc from  debian testing so it will be reliable and I can remote to that to write this blog because I am having problems with my internet again so this is written on a tethered connection on my phone. The cable is set up for internal network use only so that I can run VNC over it, and the internet connection for that computer is made using its internal wireless adapter, either to my wireless access point in the house, or to a tethered phone. So it will be a lot easier to use bedroompc for this than pc4 because I don't need to keep switching one of the KVMs over to pc4.

Thursday, 20 September 2018

Life with KDE [5]: Install on Debian over XFCE

So I haven't written too much on this blog for a couple of weeks. Now I am writing about KDE because I have decided which computers will have it and which won't. serverpc gets it installed because it is fast and has 16 GB of memory, and mediapc will be the one that doesn't because it only has 4 GB, this is the one that will stay on XFCE for now and at least have working MTP which KDE doesn't do very well at the moment.

So for serverpc instead of installing Debian 9.5 from scratch (a big deal having to reinstall at the best of times, though with my systems configuration with a separate system drive, nowhere near as big a deal as reinstalling Windows) I decided just to install kde-full package on top of XFCE, using Synaptic to find the package and it's quite a big download, nearly 900 packages of dependencies in all, something like 2.5 GB.

At the same time I am changing screens around yet again because the most optimum use of screens is a key issue and serverpc really needs two screens to make the best use of it, one portrait and one landscape. And with another screen added on for pc4 and pc4's screen getting added to mediapc it can all work, because mediapc doesn't need both of the screens it currently has so one of those can go to serverpc with minimal work, just changing a few cables around.

Anyway back to that KDE overinstall. Synaptic had some problem with a missing package so I just did it in a terminal with apt install kde-full and away it went. You will get a popup screen asking which display manager you want to use, lightdm or sddm. This is because XFCE on Debian by default uses lightdm, and KDE uses sddm. So of course I chose sddm. Now the only real issue is the command that I use to rotate the logon screen is in the lightdm config file and doesn't apply to sddm. However as you only have to type in the password it is only a small thing. 

There are a few extra things that are worth installing: eog and viewnior as image viewers (in this case already installed by me under XFCE), and pcmanfm-qt and thunar as additional file managers. The latter two are improvements for the following reasons: pcmanfm-qt (from LXQt) doesn't have the annoying Dolphin/Thunar behaviour of trying to reconnect network shares that may not be connected (which also affects KDialog). Thunar (which does at least have the option of turning off network drive management, unlike Dolphin) has the bulk renamer built into it, which I have used a lot. But Thunar is already there anyway, being part of the XFCE install. I also like the PopupLauncher widget which I use as a favourites menu instead of the KDE one; partly because repositioning the KDE launcher to the right corner of the taskbar causes it to default to the Leave section of the menu when opened, rather than Favourites. 

What you do have to be aware of though is that you now have more than one session and by default the XFCE one will load, which puts you back into XFCE. This is how you can run more than one desktop environment at a time. It's a little bit weird to see some KDE widgets running under XFCE. If you want to stay in KDE then either you change the default Xsession (the first one in the list) or else remove all of them other than plasma (which is the one for KDE). In previous times I have simply renamed all the others except the one I wanted. This time I chose to change the default xsession away from XFCE, and leave all the files as they were. The command to change the default Xsession in Debian is as follows:
update-alternatives --config x-session-manager
When you run this it gives you a list of, in my case, four options, which were:
0 - the default
1 - startkde, the command to start KDE
2 - startxfce4, the command to start XFCE4, which was the current default
3 - xfce4-session - I have no idea how this is different from startxfce4

There are a few other situations that create more entries. Notably, if you install Kodi, it installs its own session. And of course, if you have more than two window managers, there will be even more. The session files are actually stored in /usr/share/xsessions directory and are .desktop files like the ones that create application launcher / menu entries. So after rebooting, KDE was the default.

mediapc had some issues, among them non working MTP so I reinstalled it with Debian 9.5 expecting to see my experience of other computers when MTP automatically came up after installation. This didn't in fact occur this time and I had to complete the MTP setup manually as shown on this page from the Debian wiki. Basically you just install mtp-tools and jmtpfs, reboot and it works in Thunar as expected. On an Android device there may be a device menu you have to go through to choose the mode; my Nexus defaults to charging and you have to go into Settings -> Connected Devices -> USB (Android 8.1). On the other two devices I tested (Moto and Galaxy J2), this setting cannot be accessed directly from the menu; instead you have to watch for a notification that you are connected via USB and you can change the setting through that. It is not necessary to enable developer mode. As it happens on both of these it defaults to MTP making a setting change unnecessary, unlike the Nexus.

From experience so far with KDE a number of the widgets aren't optimised to save space, and so on my two screen computers, I have three panels: the two along the bottom for tasks and launchers, and a third one on top of the secondary screen for the other stuff, like the disk free space, system load, clock, system tray and notifications etc. I tried having this on the side of a portrait screen but the widgets in some cases won't work on a side panel. So then I have ended up with it on the top of the screen where unforunately it has to be a double height to work with some widgets, but I can get by with that on the secondary display.

Rearranging the screens has now been further extended by adding another screen over the desk for pc4 so it can be used easily again. Otherwise there would be little point in having pc4 at all. To achieve this win10pc has gone down to a single screen in landscape mode (for compatibility with Remmina when remoting to it, which is the way I use it 99% of the time).

Saturday, 25 August 2018

KDE remote desktop sharing

One of the best things about KDE is the amount of apps they have available that are integrated into the shell. As XFCE lacks its own remote access integration you have to install x11vnc and muck around trying to get it to run as a service which I have yet to be able to complete. In KDE you have several apps available, I chose to use Krfb (RFB is the protocol that VNC uses) and it comes up as "Desktop Sharing" which is essentially the correct description of what I want to achieve.

With just a few clicks I was able to enable the desktop sharing and also enable it as unattended because I want to be able to connect to this desktop all the time without having to go to it to authorise a connection.

It will be interesting to see how Plasma develops in its latest high efficiency optimisation. It is quite possible some of my computers will be switched to KDE instead of XFCE but there is no huge rush as I just want to spend some time figuring out how everything works with KDE. Most of my PCs are fast enough to have few issues with the somewhat greater resource use in KDE and I will be keeping Debian as the base OS, no more Ubuntu for now. 

The only real thing with the Debian install of KDE is the clunky default logon theme which you'll want to change to the Breeze logon, for which you have to install additional packages. I last had a play with the Breeze logon when I had LXQt on one or two of my computers. Incidentally LXQt is now an option to install in the Buster alpha and the next release of Lubuntu will use it by default.

One of the reasons KDE looks good is because they are making steady progress towards integrating Wayland, something XFCE is falling further and further behind on. Pretty soon Wayland will replace X11 as the default display protocol and then some of the Linux desktop environments will not support it very well. Interestingly enough Ubuntu 17.10 installs Wayland by default (Xubuntu doesn't, so I won't have seen Wayland on anything yet). In Ubuntu 18.04 they reverted to Xorg after discovering Wayland still has some issues.

Mainpc at the moment is getting reinstalled with Debian and KDE because some sort of stupid crap bug resulted in an apt autoremove command removing a lot of core install packages including all of LibreOffice and some essential stuff, basically stuffing the system and making it unable to connect to the internet. So Debian 9.5 will be on it along with KDE and this will be only the second time I have tried KDE on one of my major computers that I use every day. This time hopefully I can make it stick (last time it was too hard to migrate from XFCE).

Monday, 30 July 2018

General update

Since last time I have been doing a lot of setup stuff with various computers.

Win10PC is gradually getting set up, the only stuff I really need it for is a handful of things like downloading gigabytes of maps or whatever, scanning, ripping DVDs and bulk Irfanview stuff so it isn't moving along very fast but it is what will get used when I want to view charts with the keyboard as the screen is set up vertically for that, and having VNC running on it means I can do just about everything from over here at my desk without having to change seats. At the moment I still have to get the scanner and printer hooked up to it (well probably only the scanner because the printer can go onto mainpc). Unfortunately the storage spaces thingy doesn't actually work the way the RAID mirroring used to work (it only works with full disks, not partitions) so RAID won't be possible but I can move the home drive to the second disk and that is how I will set it up. There won't actually be anything on it that matters anyhow because of the limited tasks it is used for.

serverpc is going very well after getting its disk capacity boosted last week as I had to restore the home volume after backing it up as that was the easiest way to restore it without having to leave one of the old disks inside it, putting the backup disk into the removable drive bay is easier. I took the opportunity to dump all the config files especially as some of them didn't get backed up properly and wouldn't restore, which hasn't really been a big problem for restoring. The main task at the moment is to get all the backups of the other computers working again as with the reinstallations they all need stuff put back on them to make the backups over the network function correctly.

mediapc has also been reinstalled. I had put Xubuntu on it because it has better stuff for working with phones and things, but the biggest issue is with Cosmic, maybe because it is a beta or maybe not, that I just could not get it to hibernate. In the past it didn't matter if it could hibernate or not, but with the different uses I am putting this computer to, I need to be able to save the session and come back to it. On Ubuntu hibernation is disabled by default and even when it was supposedly enabled and the hibernate button was present and did something when you clicked it, the computer was actually turning off instead of hibernating. So I decided the simple answer was to put Debian 9.5 on it, but I failed to notice that the second screen would turn itself off (just a little side effect of having a TV as a screen and it has a no signal turnoff timer that can't be disabled) and then the logon greeter (the Linux name for the logon screen, which in MS parlance is called the Winlogon) tried to come up on the TV because it was still detectable (soft off and hard off are different because in soft off the display can still be detected). So after a lot of installation attempts that were seemly failing I just moved the mouse accidentally at the end of yet another attempt and the mouse comes back onto the active display and there is the greeter. So I was able to install 9.5 out of the box after all. I configured the spare SSD partitition as /tmp and lost some stuff I had downloaded onto it, but I will be able to download that stuff again.

bedroompc is working well with the network cable in place to be used for VNC and other non-internet networking (so grsync can run real fast) so that it can work well for internet connectivity via a tethered phone when the normal internet I have is off. I have used it quite a lot for this purpose, but still have a lot of data left at the the moment.

pc4 (for want of a better name) has Buster Alpha 3 running on it and I synced down the entire copy of my media library from bedroompc while I was reinstalling mediapc, this happened very fast over the cable. So I played media on it while I was working on mediapc with the various install issues that had that meant what should have been a simple install took about three days to complete.

And of course mainpc just toodled along like usual but I am still finishing off setup having reinstalled it not so long ago. I will set up the spare SSD partition as /tmp on both this computer and serverpc. So that's coming to the end of the productive window of today, when I will soon break for tea and then move onto other things for the evening. 

Friday, 4 May 2018

Lubuntu LXQT still not ready for release, but can be manually installed.

As it will be generally known, the Lubuntu community are working towards migrating their platform to Lxqt. I have been testing a whole lot of VMs running Lxqt as a desktop environment and it looks good even if it is incomplete.

I have run it on my bedroom computer using a test install but there are issues with the wireless drivers which I am unable to make work and it may be a question of trying to fix these up or moving to the stable release of Lubuntu 18.04 until such a time as I can install Lxqt on top of that as the packages are not currently available to work on top of Lubuntu 18.04.

Failing that I may have to go back to Xubuntu and see if I can put Lxqt on top of it as it will be nearly the same and should work well. The issue with Lubuntu is while they have been working on the new release they have pushed it back yet again.

I decided to reinstall with Lubuntu and then added the lxqt install from the package manager. To get it working I also had to separately install the sddm display manager. This resulted in a Plasma login screen but set to log in to the Lubuntu QT session. At the moment there is an issue with PulseAudio but otherwise it seems to work very well and the wireless even worked during installation. So it looks like apart from the odd glitch I have it working. The Plasma login screen which is really nice looking is an added bonus.

The audio indicator which also apparently stops the up and down volume controls on the keyboard working is not a big deal in that configuration because the hardware volume control in this case is easily accessible. Perhaps this is more an issue with LXQT and will be fixed in a future release. The wireless driver is a much bigger issue and to find that is properly addressed and works flawlessly is a much more major issue and I am pleased that is resolved. There may be a way I can get Kodi's own volume controls to work with the keyboard in any case.

After doing some more work on this I uninstalled pulseaudio and are now using ALSA audio controls which seems to work perfectly and the volume control buttons on the keyboard also work properly and the master volume control for the system can also be set to full which produces much more output with a quiet audio source so that is what I have been able to make work with LXQT. So everything is great now.

Wednesday, 11 April 2018

KDE vs XFCE [2]

So I have been testing some VMs to see how things compare with different GUIs running on Linux.

First tryout has been KDE running on Kubuntu. So far so good. The right click issue hasn't gone away but drag and drop looks good.

Second tryout was LXQT with Kwin running on Debian. This isn't a supported option from the install, you have to install something else first (or no GUI) and then install LXQT. It took a few goes to find the right packages, the ones I installed in the end were LXQT, Kwin and task-lxqt-desktop. The last one pulled in a lot of other software, but was the only way I could get the system to boot up to a KDE login window. However the drag and drop issue is still very much live in LXQT in this configuration. So I have shut down this VM and will not use it again. 

Third tryout is Debian with KDE from the standard installer options. Having got this VM going it seems to work reasonably well. With both of the KDE VMs which I am using simultaneously to do the aerial photography layers, things look roughly the same but they need more testing to see what the issues are. I intend to work as much as I can in these VMs over the coming weeks to see how well they work and whether they resolve these XFCE issues. But I also intend to have a look at XFCE settings to see if there are any that can resolve these issues.

I have decided against installing KDE as a replacement on my mainpc for now because it is so different from XFCE that a huge learning curve and setting everything up from scratch is needed should I reinstall with it. It does also seem to be fairly bloated with some of the installations on the VMs being very slow with tons of files to install. Using it in a VM is a useful workaround if running it natively under XFCE is difficult but there are XFCE settings that control the drag and drop and playing with these seems to be one avenue I can explore for now.

Subsequent testing in VMs has also confirmed the issues are not resolved by using KDE instead of XFCE so I plan to stick with XFCE and the KDE experiment is officially over for now.

I am also rearranging the screens with the second screen for mediapc, which is on the left, swapping places with the only screen for win10pc, which is on the right. This will let me use win10pc's own Microsoft multimedia keyboard on its own and thus have all four keyboards easy to use, where it sits currently on the right it is too far away to use easily, but I can use the spare keyboard slide on the left (that is actually normally used for my drinking cup) for the MS keyboard being easily within reach. So then using the Win10pc as a fourth computer alongside the other three without switching keyboards becomes much more straightforward. When not in use the keyboard will still be stored on the right as I don't use this computer very much with the MS keyboard, I generally use it with one of the switchable keyboards, but there have been times when I want to use all four computers at the same time and having Win10pc's keyboard on the left and screen on the right isn't very user friendly. This also dispenses finally with the ideas about having an extra sliding shelf of some form or another on the right, I won't be doing any such thing now, what is on the right are the two KVMs and the scanner and these will remain unchanged.

Tuesday, 10 April 2018

KDE vs XFCE

Whilst I have been generally happy with both Xubuntu and Debian with XFCE as the GUI, there have been a number of issues running programs under XFCE that have caused me to doubt its capabilities. Mostly these surface with Qgis because of the nature and extensive use of the software and are in three two areas:
  • The right click or shortcut menu is almost impossible to open without accidentally clicking the menu item closest to the mouse pointer. This has been mostly under Qgis but I have lately been seeing it happen under other applications as well. This has been confirmed not to be a XFCE specific issue and is possibly application implementation specific.
  • Drag and drop in many cases is poorly implemented, that in many cases you will be dragging an item even when you aren't holding the mouse button down. This causes a lot of problems with the Qgis layer list which supports drag and drop to reorder items. Frequently layers are inadvertently dragged and dropped to wrong places in the list.
  • Double click also seems to be poorly handled and in many cases single click is taking the action where a double would normally be needed.
Up until now apart from filing a Qgis bug report concerning the right click issue I haven't done much, but seeing the right click affecting another piece of software in the last couple of weeks has spurred me forward into creating a Kubuntu virtual machine with Qgis installed for testing. So far the drag and drop issue seems to be resolved, but I need to spend a lot more time using it to be really sure. Understandably I will be testing the other issues on it as well.

This Kubuntu VM will be used on mainpc instead of the natively installed Qgis on that computer so that I can get as much testing as possible done with it over the coming weeks and that will give me time to look at whether to permanently adapt my Debian computers, probably just mainpc and serverpc at this stage, to KDE. This would probably happen when Buster comes out. There is no pressing need to upgrade all the computers at this stage.

In regard to Qgis, I have previously looked into making the raster aerials usage more efficient by scripting the copying of only the images used by extracting from the QLR file in XML. I have instead gone for a much simpler process of a simple command script that copies the manually entered filenames (with as much abbreviation as possible) running on the Windows 10 PC, to copy only the required imagery from serverpc to mainpc for each section of rail corridor that I have aerial imagery for. Hopefully this will soon progress to all the aerial imagery I have for the various corridors, and without gobbling hundreds of gigs of disk space as was happening before.

The need to come up with a backup solution is becoming more pressing and will, I think, simply consist of local Borg backups on each computer. The idea of a backup server is not well enough supported by Borg at present to work well with multiple PCs. In addition there are now problems with OverGrive which is a Linux sync client for Google Drive, which I rely on to do backups of map projects and data files. Google has changed its API yet again and typically they will drop support for an old API at the same time so I have been shocked to discover OG has no mechanism for flagging upload errors which are being reported in its log. It turns out the OG developers have abandoned it.

UPDATE: Because buster is probably as much as year to 18 months away I am looking at putting KDE onto mainpc as a replacement UI install, rather than doing a completely new install. It takes a bit of work to make it the default replacement for XFCE. I am also going to test out LXQT in a virtual machine, this is like LXDE but updated to use QT components and therefore has a more modern appearance than LXDE. Both environments will be tested in VMs before installing them, I am about to build a Debian 9.4 VM for LXQT testing.

I have decided to continue the "backup server" model with Borg but there will be separate disks for two different backups. One 2 TB disk will be mainpc by itself and the other will be for mediapc and serverpc combined on one 2 TB disk. It may be that I need to buy some more disks, but at the moment there isn't really any money to spend on these. I will begin testing out Borg for this very soon. There is a free replacement for OverGrive but without the automatic detection for uploading so I have to think about how to install it.

Tuesday, 20 February 2018

New bits for "old" computers

As of today the new SSD for the bedroom PC (NUC) and the one for the "server" have arrived. The NUC has now got the SSD installed and Xubuntu 18.04 (Bionic) installed on it and the video clips now being downloaded over the wireless from the mediapc. The difference in sound level is quite notable as at night with the thing idling the HDD whine was very obvious, it also shows up that the NUC must have a very quiet cooling fan fitted. 

The "server" project was mentioned previously. Since writing that, I have decided to rebuild it into a full size Inwin desktop tower using my stock of these ex HCS which I obtained as their older desktops were retired. The shelf it sits on under the desk therefore needs to be lowered to accommodate the additional height but the main advantage of this chassis is more HDD bays internally and better access to them should a disk need to be replaced. This chassis will have a 128 GB SSD installed as the new boot disk and I am still considering the addition of another 8 GB of RAM to make it more useful if I can afford the cost. The shelf instead of having three brackets bolting it onto the desk below, will have two much more substantial brackets bolted to the side of the desk above it.

The existing Inwin mini tower the "server" components are installed in will then become the chassis for the Windows PC which will be removed from the Antec ISK110 case. This will fit under the other side of the desk in the space where the printer currently sits, side on. A shelf is going to be put above the computer which will slide out on drawer rails and this will be for the scanner which will make it much easier to use because of the limited access under the desk with the keyboard tray for that computer above it. The shelf will be one of the 600x400 melamine shelves I currently have, which will have to have about 40 mm trimmed off one side.

The Antec ISK110 chassis could then be used with the other mini-ITX board I currently have as a small Linux server. I am currently looking at what sort of things I could use it for, possibly a small comms server for school productions is an option with the free edition of 3CX running on Debian. I would have to get hold of a few spare phones for this.

The printer is getting moved and it will sit on top of the office drawer unit which at the moment sits at the end of the desk. An extension top will be bolted onto the top of these drawers being another 600x400 melamine shelf using what are called "Tee Nuts" which is a nut that can be made captive by hammering it into the hole, whereby it has shoulders with pointed tips that penetrate the wood and lock it into place. A regular bolt is then bolted through from the other side. This is much more preferable than using regular screws. The shelf apart from the printer will also carry the fan or heater which sits on this side of the desk and drinking glasses.

The use of other storage in the living room is still being considered, in particular the pigeonholes in the big cupboard, having moved that from the left side to the right side of the desk. I need to figure out the best use of this space and whether to keep some of the computer related stuff out in the sleepout. I feel sure the space in this cabinet can be better utilised, at present I have yet to store everything in it but don't want to pile stuff in and then discover it fills up too quickly.

The future of my collections of photos is one of the reasons for making the scanner more accessible. I am seriously looking at getting rid of the photos to the NZRLS archives and in order to make it easier for them I would be scanning them first, as they are currently underway with a project to scan their entire collection. This would let me keep a copy of the photos electronically for any future use I have for them, while freeing up the several boxes they currently sit in. Although the space of those boxes is not great, it does help to reduce the overall clutter in the house.

Another storage issue is having got rid of the filing cabinet, I still have files, so storing these will have to be solved in future. I have had a look at various plastic boxes that have rails fitted for files, as well as a smaller filing cabinet (than the one I got rid of). At the moment all the files are piled up out in the sleepout and finding an ideal way to store them is another goal for reducing clutter as I can't see a better way of storing the contents.

Sunday, 24 December 2017

NUC as HTPC or small portable computer [2]

Last time I posted about this. Here are some further thoughts after using a NUC for 2 1/2 weeks. In addition to HTPC, I took the NUC with me on a holiday in the south of New Zealand, leveraging its tiny form factor to save on transport space/weight.

The NUC has been a very useful and dependable replacement for the AMD E350 computers I used to use in the HTPC role at home. With current driver support available in Xubuntu, the graphics performance is very satisfactory, as is other performance. While down south I used it to run the maps drawing software Qgis as well as for more general tasks, and it handled the heavy load of rendering the screen and composer output just fine. If anything, the hardware does seem to be quite fast with a Celeron J3455 quad core and 8 GB of RAM compared with the Pentium G dual core and 24 GB of RAM in my main pc. 

The main issue you do have to be aware of in these NUCs is the built in wireless capability. The internal wireless card which is preinstalled comes with a couple of small antenna wires already attached to the case. The performance of these will not be as good as a regular whip antenna so you have to be careful with where you put the NUC. On holiday I was only getting 1 Mbps from the campground's free Wifi which was very disappointing and almost unusable (the iwconfig command is used to get details of wireless performance). I even burned through several GB of Vodem data (and had to pay topup charges as well) to be able to use the NUC to do all the usual stuff that I do at home on the internet. However as soon as I raised the chassis to a high windowsill the wireless speed vastly improved to around 65 Mbps and now everything seems to be working just fine. Even at home the wireless speed is slower than what the Ubiquiti wireless bridge cabled onto the old computer was capable of, but I will have a look at the location of the box if I decide more speed is mandated.

Thursday, 7 December 2017

Using a NUC as a HTPC

So I have been having a play with a NUC as a HTPC. It looks like it could be a good replacement for the AMD E350 I am currently using to play movies and do a few unrelated things in my bedroom.

The main issue with the NUC is getting Linux support for its hardware. So I chose to test it with Xubuntu because Intel specifically supports only a few distros (Ubuntu and Fedora particularly) for hardware. This makes it easier to get the drivers needed (there is a wireless and bluetooth card built into the one I am testing, the NUC6CAYH which can have one 2.5" laptop HDD and up to 8 GB of RAM installed).

There have been issues in the past with EFI support for NUCs. Suffice it to say I couldn't get Debian to boot on the NUC. But the installer for Xubuntu was able to do the EFI install properly. It is the first time I have set up a computer by choice as an EFI installation, which requires a new skill set - a separate 300MB FAT32 partition is required specifically for this function. The system restarted just fine - it looks like the Xubuntu installer puts the required files into the folder to be compatible with what the NUC expects to find on startup.

The messy part was updating the NUC's firmware - the update tool provided by Intel only works on Windows 10 x64, so I have had to install that first, then run the updater, to ensure it has all the updates needed. After that I took Windows off to install (firstly) Debian, which couldn't boot as the Bios wouldn't recognise it. At that point I did some checking for compatibility issues and decided to go with Xubuntu and using the UEFI boot. 

Out of the box it looks like most hardware is OK - it recognises the wireless card, and possibly Bluetooth will work, which will be interesting. I used to use Bluetooth on mainpc to transfer photos and files to my phone when I wanted to post on Instagram or something like that. It was flaky however and I haven't bothered with it since reinstalling some considerable time ago - possibly Debian doesn't have the driver stack installed by default - because I started using Google Drive to transfer stuff instead. I can't think of any particular reason to use Bluetooth with a HTPC so it probably isn't that big a deal. It would only be useful if I could use it to play music from a phone to the HTPC's speakers and I am pretty sure that is not possible.


Their claim to fame is to be a very small package - smaller than a Mini-ITX, which is partly achieved by having sideways memory sockets, eliminating any slots on the board, and having only a single SATA port and limited other headers etc. Another part of it is that the CPU which is a Celeron J3455 quad core, is mounted directly onto the mainboard without a socket, and because it has a very small TDP of only 10 watts maximum, the fan needed can be quite small as well. In fact it is possible in the Bios to configure the system to turn the fan off when it isn't needed, and in truth I have never noticed the fan running, it must be very quiet.

The system has four USB ports, VGA, HDMI, SD card reader and two sound connectors one of which doubles as an optical and analogue output. It comes with a universal power adapter with different plug heads so you just clip on the plug head that fits your local mains socket. It comes with a VESA mounting plate which as we all know can be used just as a general wall mount or whatever. The system uses an Intel visual bios which has the annoying habit of not recognising the Logitech multimedia keyboard I use properly - specifically its function keys, so I have had to plug in a corded keyboard to change the Bios settings.

So now I am using Xubuntu again - this doesn't mean I have any intention of switching any more computers back to it (especially since mediapc was upgraded to Debian recently) - it is just easier on the NUC because of better hardware support. Debian would tell you on startup about a pile of missing firmware files in the Linux kernel - Ubuntu has installed all the right files itself so it just works without all the error messages.


Monday, 27 November 2017

More Debian

Since last writing the remaining Linux computers in the house have been changed over to Debian. As usual this has been a straightforward procedure, in the case of mediapc reconnecting the RAID array being as simple as it was on mainpc. All computers use XFCE as their desktop environment.

There are now four computers in this household running Linux and one running Windows 10. The possibility is that the Windows 10 computer will be changed to the lowest spec one due to the fact I use Windows quite rarely and struggle to see the rationale in having a computer sitting there not being used a lot of the time. However the case for the fourth Linux computer isn't that great either so of the four computers on this desk, at present the lowest spec one is running Linux and the 3rd lowest runs Windows. The other issue with switching computers is ensuring there are enough USB ports as there are quite a few camera cables and other devices plugged into the Windows computer such as the printer and scanner.

Due to now having a fourth computer at my desk (a small form factor that used to be playing videos in my bedroom) it is using its VESA bracket to mount on one of the monitor support posts at the side of the desk and has its own keyboard and mouse plus the KVM to share the main keyboard/mouse. It has one display of its own plus sharing a display with the mediapc. At least this lets me make reasonable use of it to do some actual work on.

Debian 10 is a test installation as this is a development version of the software but it will run Qgis development edition and I am using this where I can and may install additional applications to see if I can test out this version of Debian reasonably well. I may have a look at a good audio editor if ones exist to see how well it would work on the platform.

The bedroom PC is hopefully getting replaced with another low-end system but using better supported hardware (Intel chipset) that can play videos because this has been an issue with the AMD E350 board (the same board also in the 4th computer on my desk). Since AMD has dropped support for the Radeon chipset on these boards in Linux as well as Windows, these computers now struggles to play even Youtube videos full screen. I could put an older version of Debian or Ubuntu on it and regain that performance but replacing the computer with one using Intel chipsets is the preferred scenario. 

Thursday, 5 October 2017

Upgrade mainpc to Debian 9.1 [2]

Well as usual I have decided to rush in boots and all and get Debian on this computer. Creating the pen drive for the netinstall image that I used previously to create VMs was a little tricky until I realised it had to be in FAT32 format rather than ext4. The Debian installer threw up a warning about using the Unetbootin tool to create the pen drive, but it worked flawlessly. The installation is practically the same as Xubuntu except you get a choice of desktop environments, from which you can choose, in this case, Xfce. It being old hat I soon had the partititions set up on the SSD (2x 60 GB, one the boot partition and the other swap) and the installer flew along as expected. One of the reasons for wanting to change the installed OS is some issues that have come up with Xubuntu 17.10 which naturally proves one has to be careful about installing the latest bleeding edge in a production environment. For this reason I decided not to install the testing repository and will find some other way to update Xfce if it is an old version.

Once having completed the base install the next step is, as usual, to set up the RAID array, which we do by logging in as root and then installing the RAID software and configuring it, just as I have numerous previous times. I'm being incautious by not having made a backup before starting the install, but I did have a backup done a couple of weeks ago, and there are two disks in the array that are exact copies of each other, and it's unlikely to be an issue to get the array working again. So actually it was very straightforward. So now for the rest of the day I will just be tweaking the installation and re-installing bits of software on the computer. As usual as soon as I pointed /home at the RAID array and then logged on as myself everything came back especially the XFCE panel and menus and it is hard to see any difference from Xubuntu. One of the key things I can do with this version of Debian is natively install a stable version of Qgis master alongside the most up to date version and at the moment it is building an installation from source that should work OK as it has on all the VMs I have put together up until now with Debian on them.

[UPDATE] So MainPC has been OK. The PC in the bedroom crashed a couple of days ago so I just jumped in and installed Debian on it as well. This is a bit tricky to do in general because of the differences between Debian and Ubuntu, and it took a bit more work to get it up and running. I still have to install a bit more software on it to finish it off, but it is going fairly well. I don't have a plan to migrate all the computers, and will only address it whenever it is necessary. So I still have one PC running Xubuntu and have no plans to change that.

Upgrade mainpc to Debian 9.1 [1]

I wrote about this last time. Like all the other times I have upgraded this will be a multi step process because of the various things needed on the system. However none of my other computers will be changed from Xubuntu. I don't have any real ideological reasons but I do want a system that is more widely supported than Xubuntu and yet still has the Xfce desktop interface which is light and fast. I remember that I tried Debian one time before and didn't like it for some reason, but I think that time is now past and I will go ahead with the upgrade this time. Probably all of the other computers will stay with Xubuntu (Artful currently).

To get more up to date packages the system needs to have the testing repositories added to apt, this is simple enough to do with a line or two in /etc/apt/sources.list:

deb http://ftp.nz.debian.org/debian/ testing non-free contrib main
(you may also have a deb-src line as well)
which gives me access to the NZ repositories for testing. When I put this into my test VM and ran apt update it said there were 778 new packages available. Whether all of these actually are required is somewhat moot as the main issue is that the system is pretty well stripped down to the minimum required components - which is probably going to be the case anyway. There were actually 892 gets needed which took 11 minutes in total to download. About the same amount of time again was needed to install everything.

So this is just an early stage of looking into it because there are numerous steps to follow and there will be reinstallation of the software and various disruptions etc.

Wednesday, 4 October 2017

How to set a custom display resolution in Xubuntu

This is the way to mirror my pair of screens on my bedroom PC. One screen is 1360x768 (a little odd) and the other is 1680x1050. The default mirroring in XFCE will only run them both at a 4:3 resolution like 1280x1024, since this is the highest resolution they are both compatible with, even though the aspect ratio is wrong and so a part of the screen is not actually used.

x.org server ships with a command line tool called xrandr. This is capable of changing the display settings on the fly and in this case the command we want is either of the following:
xrandr --fb 1360x768 --output VGA-0 --mode 1360x768 --scale 1x1 --output HDMI-0 --same-as VGA-0 --mode 1680x1050 --scale-from 1360x768
Alternate form (which I also tested): 
xrandr --fb 1680x1050 --output HDMI-0 --mode 1680x1050 --scale 1x1 --output VGA-0 --same-as HDMI-0 --mode 1360x768 --scale-from 1680x1050
Which one you use will depend on which screen it is more important to run in native mode. At the moment I am using the first option, as it gives a native size picture on the 1360x768 screen which is the easiest to read bedside screen. The important difference over what xfce4-display-settings can achieve is that one of the screens can be scaled to match the other. It would also be possible to have some oddball configurations like three displays with two of them an extended desktop and one mirroring one of the others.

Running this command only lasts as long as the next boot. In order to make it come into effect at every startup it needs to be put into a file that the LightDM window manager executes when it initialises.

In this case, after looking at the Ubuntu documentation over here on the wiki, I made a file in the path /etc/lightdm/lightdm.conf.d and called it 50-myconfig.conf

The contents of this file are just two lines:
[Seat:*]
display-setup-script=xrandr --fb 1360x768 --output VGA-0 --mode 1360x768 --scale 1x1 --output HDMI-0 --same-as VGA-0 --mode 1680x1050 --scale-from 1360x768
Basically display-setup-script is a prefix that tells LightDM to run this command after it starts the X server, and then it is the xrandr command I mentioned above.

Just as an aside, right now I am looking at putting MainPC to Debian 9.1 with XFCE as the front end. The issues to be resolved will be how to get a more up to date version of XFCE than the default from the Debian repository, this will probably entail using the unstable repositories. This will all be tested out in a VM before migrating. No other computers are planned to be shifted, it is mostly about getting the best system on a PC that is used for the most work I do.

[UPDATE] When I reinstalled the bedroom PC with Debian recently I had to put this setting back in to the computer. The PC is also using XFCE as its GUI and the settings were the same, except I put the display-setup-script line into /etc/lightdm/lightdm.conf file. An interesting twist was I had to install some extra packages for Radeon drivers before Xrandr could detect the display settings and ports properly. Since there have been questions over video performance on this computer with late releases of Xubuntu it will make an interesting comparison. Although, this tiny PC is to get a makeover soon with a Asrock Q1900 board that will run Intel chipset and graphics which will help a lot because of better support in Linux.

Friday, 29 September 2017

Using VNC for remote control again

One year ago almost exactly I wrote about using VNC with a couple of home computers. My computer arrangement after that date was changed and remote access was not needed between two rooms of the house. However this week I have decided there are scenarios for remoting from the bedroom to the lounge where three main computers are. Mainly that it will enable me to do some computing stuff and have a devotional time at the same time in the bedroom as that room is set up for devotional time and there are many small tasks that can be done on the computer that don't need me sitting in front of it all of the time. So in enabling me to increase my devotional time which is what I really want to be able to do. It is also better for being able to work on the computer while in bed so that I can avoid staying up way past my bedtime as I have at times. Bed is a much better place to be if you are tired as falling asleep in front of the desk is risky since many times I have fallen off my chair and landed heavily on the floor.

Remmina as a client and x11vnc as the server are the combination used just as my previous post described and Remmina presents the screen as two windows side by side that you can just move the mouse to the edge of the monitor to scroll to the other screen. I will not be setting up remote access to the other computers in the lounge as it's only MainPC that really justifies this. Since for more indepth stuff I can just work in the other room. Working from in bed at times and at other times sitting in front of a music keyboard, using a multimedia computer keyboard is not very productive as compared to a regular desk setup but I won't be doing this with the desk even though it has been fitted in the past with a keyboard slide as it has since been lowered to be at the right height for playing the music keyboard. In effect this options is really only for relatively simple tasks that do not require a lot of typing or a regular mouse in place of a touchpad. And I don't want the distraction of a full keyboard/mouse setup in the bedroom because it is of secondary importance. I already had the E350 HTPC set up to play videos and it has adapted easily to this new role with a pair of Dell 22" screens. Unfortunately at this stage I cannot used the 1366x768 Sony 32" monitor as one of the screens as this resolution is not available when mirroring the screens so cannot use a 1680x1050 screen mirrored with the Sony so 3 screens in the bedroom for now.

I had already been using a second screen with the computer (2 screens mirrored) to serve a dual purpose of enabling me to look at PDF music charts with my Casio keyboard as well as this second screen enabling me to have the computer on while playing music for night time intercession, a common scenario because of time differences doing international intercession, since I can just turn my head to the opposite side of the bed and the light from the screen won't keep me awake. At a time when it is all important to have more devotional time, being able to use this setup is really useful. This week I have been doing lots of small repetitive tasks on the PC that don't really warrant spending a lot of time sitting in front of it but still have to get done so being able to retreat to the bedroom is the best of both worlds and I am sure will continue to be in the future.

This is the first and last blog post written using this arrangement as being limited to two finger typing on a multimedia computer in bed is very slow and tedious.

Monday, 11 September 2017

Debian vs Xubuntu: The ideal Qgis VM production environment

So having discovered a bug in the Qgis composer as the reason my homebuilt Qgis VMs crash and not any other reason, this idea of building from source has actually been not such a bad thing at all and has left me with something that actually works all in one VM and one that is actually licensed legit because I don't actually own any Windows licenses and haven't much like relying on some legacy licensing rights to Windows environments that I will sooner or later have to update to current.

This being achieved by being able to build what seems to be the last build (313ec55) of the Qgis development master that is actually reliable, onto versions of both Xubuntu and Debian that can run a release of Qt that doesn't have a silly floating point rendering bug that never existed until quite recently and as it happens was the version deployed with Xubuntu 16.04 which is the last version that can auto install 313ec55 from the packages without installing the latest version, so building from source on a later version of either Xubuntu, or else on a late version of Debian, was the only way of getting this 313ec55 fairly stable with few bugs version 2.99 of Qgis that I can use to develop my 2.99 map projects and use for virtually every part of the process without issues. At the moment there is still a bug that relates to saving new projects or new versions of a project that needs the use of Windows because the 2.99 project format is incompatible with 2.18 in which this particular bug has been fixed.

The development masters for 2.99 are of course part of the process of developing the new 3.0 release of Qgis and I guess there will soon be a 3.0 version out, probably in a couple of months, and hopefully all the bugs will have been fixed in it.

However a big discouragement is that the latest builds have introduced an incompatible project format and the developers have said they do not care that their new software is incapable of reading and converting older 2.99 project formats because they don't guarantee to support projects created with previous development versions of the software. This will have to be followed up to see if this is a new policy and is it reasonable.

In general as far as the VMs go both Debian 9.1 and Xubuntu 17.10 are very efficient with resources. A 12 GB VM will have loaded Qgis, but not a project, and have used up 1 GB of memory in total for the OS and the software. This is a lot better than Windows bloatware where the OS gobbles up memory like there's no tomorrow. You can build a really lean VM or PC optimised for low resource use and that's where a GUI environment that is optimised for low resource use like Xfce (which is what I have running with Debian on my Qgis build VMs) really shines, one of the reasons I stopped using Linux Mint (which I have almost forgotten) because their GUI gobbles resources unnecessarily.

Meanwhile the map work continues.


Friday, 8 September 2017

Building Qgis from source code

UPDATE 2: Well in spite of my comments as below, it seems I have discovered a new bug in version 2.18 LTS of Qgis as well as the home built master with the composer crashing the software when attempting to render a map. It may well be that there is a bug in this master, the 2.18 LTS and some other versions of Qgis, and at the moment I am focusing on attempting to test and document the bug for the Qgis project. So it looks like the crashes in Debian were from the same issue, and that it is possibly a bug for Linux specific versions, but it could also be an issue that affects all versions.

It looks at this stage like I will be able to use either of those home-built VMs to do my work as the crashes are probably an inherent limitation of Qgis as a whole, rather than specific to the VMs I have built from source, but it is still a perplexing issue.

UPDATE: Whilst building from source is an interesting experience my outcomes have not resulted in more reliable operational experiences with my home built VMs. Building 313ec55 on both Debian 9.1 and Xubuntu 17.04 has resulted in unstable working environments that crash a lot more than the 16.04/313ec55 and the Windows 7/11812846 VM environments that I have used up until now. It is therefore my decision to continue the development of the project on 313ec55, and another Linux VM running the 2.18 stable release will be used to produce, as it is capable of reading enough data from a 2.99 project file to properly render the output.

With a FOSS package like Qgis there will be times you want to build it from source. For me this is getting a working version of the development master because newer versions sometimes have bugs, or are unavailable on the OS you are running on your computer. Whilst it may sound like a big deal to build from source, it is surprisingly straightforward.

In my case I have always tried running development versions of Qgis, but it gets risky running them when a new version comes out and has major bugs, as is currently the case with latest builds that trash the CRS settings and fail to load some layers (possibly these are connected reasons).

 The steps for building Qgis in a nutshell are:

  • Set up a development environment. In this case, a Vbox virtual machine is the best development platform. Once you have one set up with the basics you can easily clone it, and they don't need much memory or disk space. 
  • You'll need to install some packages specific for the Qgis build.
  • Set up some folders to hold the build files, the destination installation, and change a few settings here and there.
  • Get a build of the source code from the appropriate branch on the QGIS github site. In this case the master branch. Master builds happen every day, so there are plenty to choose from.
  • After you get the zip file downloaded, check the version number in CMakeLists.txt to ensure you have the version. There are currently 48 different branches on Github and all various versions too. Near the top of the file you will see stuff like, in the case of 2.99, different variables spelling out "2", "99","0" which tell me I have build files for 2.99.0 as I want it to be. My first build attempt on a Xubuntu zesty vm accidentally got a 2.18 build instead of the master. 
  • I have tested both Debian 9.1 (stretch) and Xubuntu 17.04 (zesty) VM environments. In the end, Xubuntu was more stable than the Debian VM with XFCE, which had a few problems and crashes. Debian would be fine as long as it was stable; I found it straightforward to set up and it went well until it became unstable and had to be reset, then was extremely slow to stabilise.
  • Set up the Cmake environment using ccmake. Mostly using the default settings, but we can set a variable to provide the destination folder that our build will be installed to, for actual usage. This is important because the default will install a new build over the top of an old one, whereas we want to let each build have its own install folders, so we can (theoretically) have more than one of them.
  • Tell ccmake to generate the makefiles for the build
  • Run make to build Qgis. This will take a while, maybe an hour to 90 minutes to complete. This part is actually quite painless considering how many steps are involved, as there will be thousands of lines of output scrolling up your screen. Most files take only 5-10 seconds to build, but occasionally it all slows down as something really big gets built. There are more than 13,000 source files in the build which take up 436 MB of disk space. At 35% of the build the make had made 6500 new files occupying 200 MB which had taken about 20 minutes, so there is a lot of file crunching going on.

  • In my case I chose build 313ec55, a release with which I have had some success on 16.04. The main problem running it on 16.04 is the version of Qt which has a bug that causes decimals to be rendered without rounding, this means a distance that you want displayed as 214.38 km will often show as 214.37999999999. In order to address this I followed the instructions (despite warnings) to build against Qt5 and the version that installed from Ubuntu's zesty archives was 5.7.1 which has the fixes in it. 
  • The steps listed for building against Qt5 with this release are slightly different than for Qt4 (recommended) but the release build of 313ec55 that has been installed in some of the other VMs I have used is built against this edition so there shouldn't really be an issue. So far there hasn't been.
  • The build went well and I am now testing this VM. Since it works and since I have fixes for the lack of files that can be opened at once (see a recent post) it looks like this custom build VM will be the ideal environment for both developing and publishing the maps since it eliminates the main restriction that has existed to prevent publishing from being done with a Xubuntu VM based version.
  • It looks like a lot of more recent builds (from June) have the serious issues with project data not loading correctly so I can't expect to find a more reliable later build and they have other issues with the designer that I don't like either.
  • 313ec55 still has an issue with relative paths not being followed, I have not been able to find out which later master build fixed the issue. If I have to save a new project at any stage, a Windows VM running 1182816 will have to be used, as this doesn't have this issue. 

Thursday, 31 August 2017

Linux is still miles better than Windows any day

My Windows PC doesn't even get turned on that much now. It is only for a few holdout applications like the cameras and IrfanView that I really need it for. At the moment I am using it to author some of the maps, but that isn't happening all of the time. It can cope with aerial images coming over the network and is quite quick compared to the virtual machine I was using, but Linux can process them a lot faster in a VM, so probably better still in a real PC.

Now that I have been reassured that the Qgis issue with a lot of files open isn't a bad design decision of the Linux platform then I can go back to a Linux VM to do the map design and it is faster than the Windows VM I have used up until now. The main problem is that for Linux we don't get to choose which edition of the master can be installed. Hence a need for an older master can be a problem, and explains why I use a VM running Xubuntu 16.04 as it will always pull the 313ec55 build if you choose not to use the ubuntugis repository. There is an option that I could pull 313ec55 from the repository and build it from source on 17.04 or even mainpc and therefore have it running reliably and doing all the things I need to.

Now here is a great piece of software to analyse free disk space: Baobab

This does a great job of analysing disk space usage graphically on a PC. As you can see I have an issue that my home folder is using 1.5 TB on a system with at most 2 TB of disk. Sooner or later I will have to clean out some stuff like all those aerial photos I have downloaded to draw maps, and some of the virtual machines I have installed under Vbox.

Fix for Qgis unable to open lots of aerial images on Linux editions

After some forethought the lovely Qgis people have come up with the issue being a limit on the number of open files. This is a deliberate security feature designed into Linux. Fortunately it is not, as was first alleged, an architectural limitation of Linux.

I have used the prlimit command with --nofile to increase the limit from the default 1024 to 10000 which deals with the problem most effectively. In order to make this limit increase permanent I changed the setting in /etc/security/limits.conf

This means I can go back to using a Linux virtual machine instead of a Windows one to work on NZ Rail Maps projects. Specifically I will be using a VM running Xubuntu 16.04 and Qgis version 2.99 build 313ec55 which has the fewest issues of Qgis 2.99 builds for Linux. This is actually the last master build available for Xubuntu 16.04 due to architectural changes. With testing the Linux VM running a project with a large number of aerial images open, Qgis handles the images much faster in Linux than Windows.

I just can't remember right now if there were other issues in Linux that made me switch to Windows, I think off memory it was mainly to do with being able to run different builds on the same computer (which was a physical computer for a while). This is much harder to do in Linux as the packages are not specifically configured for this option; when you update to a new version it always installs over the old. However running different VMs is one way of getting around it. Windows editions don't auto update as Linux does (when you run apt upgrade) which is handy. EDIT: There was one issue and that is to do with the rendering of distances on station labels, with 21.2 being commonly rendered as 21.1999999 for example. This means I need another VM running a different edition of Qgis to produce the outputs. 

Coincidentally this fix came the same day as another longstanding problem was resolved at home; this one concerned the power supply to my house which has been unreliable, with significant drops in voltage being experienced on two previous occasions. The last one in February or March this year resulted in a call to Orion, who subsequently claimed that as no other customer had experienced the fault, it must be inside the house, and therefore outside their responsibility.

The problem started to occur again this week and had been observed on three days up until yesterday but as usual being an intermittent fault made it difficult to diagnose. But in this case I was helped when I discovered my next door neighbour, who is in the other flat within this property, which means our flats have separate phase wires and a common neutral wire from the power pole, reported the same issues. When we managed to get Orion to come out they said the most likely scenario was a faulty neutral connection. After two separate visits in the same evening they have replaced all three neutral joints: the one on the outside of the house, the one on the pole directly outside the house, and the one on the pole on the other side of the road where our power is actually tapped off from the lines network. And in spite of all the time lost in the evening, the power supply has been rock solid since, although we had to call them back when only replacing one of the joints didn't fix the issue. The furtherest away joint was found to be loose and corroded so that was most likely the cause.

Thursday, 24 August 2017

Artful release date set for 19 October

So the date for the Artful release (17.10) of Xubuntu has been set for 19 October, about eight weeks away. I have been running it on all three of my Linux computers for several months and have noticed only a few minor issues. 

Mainly the issues boiled down to:
  • In a number of cases I have had to configure third party repositories to use zesty as the release as few of these seem to have considered that they should be making a version available for artful, even development versions like Qgis.
  • Kodi not being available from the official Kodi repositories in a compatible version. Solved by using the version from the Debian repository
  • There has been an issue on the mediapc with Kodi constantly freezing after restoring from hibernation.
  • VirtualBox did not update to the latest version automatically from the zesty repository, but the version downloaded from the website manually did update. The manual update was necessary because the installed version of virtualbox stopped working after a major package upgrade.
In each case when there is a software freeze or some other challenge I try updating to the latest release. Almost every time I check for new packages there have been hundreds of updates. It is not particularly unusual to have three hundred new packages each month and it can take easily half an hour or more to install them all. However all these updates have gone smoothly.

The mainpc has been a lot more reliable hibernating since I got rid of the Nvidia 4 head card and used the cheap two head card that is supported out of the box by the Nouveau drivers. If I should want to have more than two displays in the future I could put a second two head card alongside the existing one as the Gigabyte H97-D3H mainboard has two PCIe x16 slots installed, although I think the second slot will only do 4x but for a cheap card that may well be fast enough. Alternatively using the onboard graphics would also be an option as Intel graphics is well supported in Xubuntu and the hardware supports three displays out of the box. However apart from map drawing there has been no ongoing call for three displays and the maps project is scaling down a lot at the end of this year so there is probably no real urgency to go to three displays and in fact there is a much simpler solution, now that each PC on the desk has its own keyboard and mouse then simply use, for example, the windows pc's display as a third display of something.

The usage of VirtualBox running Qgis in a Windows 7 VM has worked out very well for completing the major part of map development running an older version of the Qgis development master because of major problems with later versions. The best thing about the Windows versions of Qgis apart from being able to handle more resources such as 250 or more Geojpegs loaded simultaneously is that they don't automatically update like ones in Linux do (if you have specified the repositories in your sources.list file or imported an update list into /etc/apt/sources.list.d) so I don't have to worry about breaking Qgis with an update. I won't be updating that VM with any newer Windows release of Qgis before the end of this year and don't know if I will bother with any of the newer versions on Linux as the later development releases with a lot of challenges and project file corruption issues among other things is not something I can be bothered with wasting time on at present. This VM has been allocated 12 GB of RAM and it is surprising to see how much this drains mainpc's resources, I guess the browsers are sucking up all the RAM in the computer, absolutely typical as they are major resource hogs, even Firefox Developer with e10s.

The bedroom pc is going to be updated with a new motherboard I am being given which is a Asrock Q1900 Mini-ITX. The advantage of this is the use of an Intel BayTrail CPU instead of the AMD E350 in the current incarnation of this computer as the AMD graphics are now deprecated officially by AMD so this computer has with the latest release of Xubuntu been having a lot of problems with graphics stuttering. The Bay Trail in the Asrock board means Intel graphics which are much better supported under Linux. I also have the option with the mini-PCIe slot on board this computer to put in a wireless card which would enable it to have wireless on board, again as long as I stick to an Intel card it will be supported out of the box. It is interesting Asrock have anticipated a few different uses for their series of board and have a Q1900DC model which instead of the ATX 24 pin power connector has a DC jack that can accept 9-19 volts DC from a laptop power adapter. If I was starting from scratch with an enclosure that didn't have its own power supply (the Antec I bought has a separate laptop style adapter and a small internal board to produce the standard voltages) then this board would be well worth taking a look at.