Every so often you want to manually invoke something that isnormally automatically run periodically. Back in the days wheneverything ran through cron entries, you did this by findingthe specific cron entry responsible for the action (oftensearching through /etc/cron.d for likely candidates), gettingthe specific command line (and sometimes the user involved),and manually running it. These days, an increasing number ofthings are switching from cron entries to systemd timer units ,so you need a somewhat different procedure.

The

Currently, Linux distributions claim that they want to stop includingeven a minimal Python 2 at some point, although when that will be isn'tclear (the latest Debian and Ubuntu in development versions both seem tostill include it). Since we have anynumber of perfectly functional small Python 2 programs used in managingour systems (and no particular time or enthusiasm for porting them allto Python 3), this presents a potential future problem, never mind thedisruption for our users (who may also have such programs

When I initially set up GNU Emacs LSP support for Python , I wasn't sure if the effort was going to beworth it for my Python programming ( which is currently mostly notusing type hints ). Although I don't edit alot of Python these days, I've come to believe that using thecurrent Python LSP server is worth the effortto set it up, although it's not clearly a win the way it is formore static languages like Go.

(I'm not

The Cinnamon desktop hasa wide collection of things that can have keyboard shortcuts assignedto them, and a somewhat smaller collection of keyboard shortcutsthat are actually assigned to them by default. If you want to examineor change what any particular Cinnamon action is bound to, you cando this through the System Settings applet, in the "Shortcuts" tabof the Keyboard settings. Remember to click open the little trianglesto reveal all of the setting categories.

Unfortunately, as far as I know Cinnamon doesn't have anything

About a year ago, I gave in to a temptation and got myself a UPSfor my home desktop and the thingsattached to it, including my DSL modem. When I bought it, I expectedit to be almost entirely an indulgence, which I justified to myselfas insurance against a very badly timed local power outage while Iwas in the middle of something important while working from home.

(At work, power outages are too rare to worry about, and one thattook down my work desktop would also take

In a comment on my entry on (not) using YAML for human-writtenconfiguration files , Wolfgang Richter asked what I thought of Dhall as a standard for configuration. I'mafraid that I have to rain on everyone's parade: I don't believethat any generic and general language can be used for configurationfiles for programs that need complex configuration (setting asidesome problems with using languages, like reasoning about theresult and the general lackof clarity ).

Programs with complex configuration needs are almost

For reasons beyond the scope of this entry , I'm currentlyin a situation where I suddenly care about the amount of bandwidthmy various devices are using and want to keep it relativelyminimal. This has suddenly made me quite conscious of how commonit seems to be for programs and systems to assume that you haveplenty of bandwidth and they can use it up at their convenience.As a side effect, it's also made me conscious of how difficult itcan be to track how much bandwidth devices are using

I was recently reading Breaking the web forward ( via ), whichis in part about how Chrome keeps breaking the web because theycan. In the process, it says:

Jim Nielsen feels thatpart of the issue is the lack of representation of web developers inthe standardization process. That sounds great but is proven not towork.

One reason that it seems unlikely to work even if you could overcomethe issues the article raises is that fundamentally, having meaningfuldeveloper representation requires that the browsers actually listen,and that

One of the realities of the modern web is that in general browsershold pretty much all of the power to dictate how the web develops;it's (currently) browsers that decide what features to implementand what features to deprecate. In practice that means that Chrome(with its fairly dominant browser share) holds the power, including the power to abruptly deprecate things . But as I was thinking aboutthis, it occurred to me that a large part of this power rests onthe widespread use and acceptance of Chrome