Just performed a wanton reboot of my Modem/Router.

The modem/router which I use for my LAN is a Bell Hub 3000, which I still hold to be a good modem. But lately, I discovered a slight glitch in the way it works. I have given it numerous specialized settings, such as, for example, a “Reserved IP Address” for my new Chromebook.

The problem I ran in to was, that the modem was executing all my settings without the slightest flaw, but was failing to commit changes to certain settings to non-volatile memory. Apparently, the way the modem is organized internally is, that it has volatile as well as non-volatile memory, which mimic the RAM and the Storage of other, modern devices.

In certain cases, even a full-blown PC could be running some version of an operating system, in which a user-initiated change is accepted and enacted, but only saved to non-volatile storage, when the user logs out successfully.

Well, earlier this evening I had a power failure, after which the modem restarted, but restarted with settings, that predated the most recent settings which I had given it. This was its only offence.

Now, I could go through the ritual of changing all my special settings again, after every power failure, but in reality, that would not do. And so, what I did was to soft-boot the modem, which, just like that poorly programmed desktop manager would, saved all my settings to non-volatile memory. After the reboot, those settings have stuck.

But what it also means is twofold:

  1. This blog went down again, from 20h15 until 20h25, in other words, for an extra 10 minutes.
  2. And, if there are any readers who examine the IP address log in the side-bar of my blog, they will notice an additional IP address change, simply due to the modem reboot. This will be, between 20h10 and 21h10. This one was not due to any malfunction, but was deliberately triggered by my action.

The process was short but painful, and had to be done. :-)

Dirk

 

Kernel Update today, Downtime

I take the somewhat unusual approach, of hosting my site and therefore also this blog, on a private PC at home which I name ‘Phoenix’. This is not how sites are usually hosted. And what it means is that, while I get to play with my own server all I want, the visibility of this blog on the Internet, is only as good, as the up-time and the connectivity of this PC.

This evening a Kernel Update was put through the system, which required I reboot this Linux computer. Therefore, my site and blog were off-line from about 20h00 until about 20h15.

I apologize for any inconvenience to my readers, but these things must be done.

The kernel update itself seemed to have no ill effects, that I can detect immediately. But in all honesty, if there was ever anything wrong with a kernel update, there are essentially two types of problems which can take place:

  1. The computer immediately refuses to boot,
  2. It takes a long time to detect a problem, and when this is done, the problem is usually also detected by somebody other than me.

So because I’m back up, there’s nothing to complain about! :-)

FWIW, this computer had been running one session, for 35 days straight, with no real technical issues.

Dirk

 

“Weather Widget” for Plasma 5 -based, Linux Computers

One of the observations which I’ve made about the practical use of Linux, is that in recent years and weeks, the number of weather widgets which we can use to decorate our desktops, and which provide some semblance of forecasting, has become more meager.

I suppose that one important reason may be the fact, that companies cannot extract revenues from operating servers, which simply respond to URL-requests, and which hand out weather information on that basis, for the client software to process as client wishes. Companies will only make profits these days, if they can force their clients to view advertisements.

And so recently I installed a widget, to my Debian / Stretch, Plasma 5 -based desktop computer named ‘Plato’, which is named ‘Weather Widget’, and which has the following display available:

screenshot_20180831_105340

This widget has as option to display information from ‘openweathermap.org‘, which has as intention to remain open and available.

There was a detail in how to get this widget running, that wasted some of my time yesterday, for which reason I’d like to share my experience with the reader. First of all, the preferred way to install this widget is, to right-click on the desktop, and then to left-click on “Add Widgets…”. If the desktop widgets are locked, the command must be given to unlock them first. Then, in the side-bar that appears, we click on “Get new Widgets” (at the very bottom), and then on “Download New Plasma Widgets”. In the window that appears, there’s a search field. In it, type ‘Weather’, and the widget in question should appear as available.

One great plus to adding widgets in this way, is the fact that we can do so, in user space, that is, without requiring root. However, here comes the catch: This widget will only display correctly, under Debian / Stretch, if the following two packages are installed:

  • ‘qml-module-qtgraphicaleffects’
  • ‘qml-module-qtquick-xmllistmodel’

Under other Plasma 5 -capable distributions, the same features may be provided by packages, which are named slightly differently.

Continue reading “Weather Widget” for Plasma 5 -based, Linux Computers

Another Caveat, To GPU-Computing

I had written in previous postings, that I had replaced the ‘Nouveau’ graphics-drivers, that are open-source, with proprietary ‘nVidia’ drivers, that offer more capabilities, on the computer which I name ‘Plato’. In this previous posting, I described a bug that had developed between these recent graphics-drivers, and ‘xscreensaver’.

Well there is more, that can go wrong between the CPU and the GPU of a computer, if the computer is operating a considerable GPU.

When applications set up ‘rendering pipelines’ – aka contexts – they are loading data-structures as well as register-values, onto the graphics card and onto its graphics memory. Well, if the application, that would according to older standards only have resided in system memory, either crashes, or gets forcibly closed using a ‘kill -9′ instruction, then the kernel and the graphics driver will fail to clean up, whatever data-structures it had set up on the graphics card.

The ideal behavior would be, that if an application crashes, the kernel not only clean up whatever resources it was using in system memory, and within the O/S, but also, belonging to graphics memory. And for all I know, the programmers of the open-source drivers under Linux may have made this a top priority. But apparently, nVidia did not.

And so a scenario which can take place, is that the user needs to kill a hung application that was making heavy use of the graphics card, and that afterward, the state of the graphics card is corrupted, so that for example, ‘OpenCL‘ kernels will no longer run on it correctly.

Continue reading Another Caveat, To GPU-Computing