I recently had an issue with very slight display lag on my Ubuntu 17.10 desktop, which had a very interesting fix.
For context, I have an i5-4XXX series desktop with a nVidia GTX 970, and two 1080p Samsung BX24440 ‘SyncMaster’ monitors connected via DVI.
A few nights ago, I turned off my computer to move it so that I could switch to a new desk setup. By doing so, I allowed my OS to apply a few kernel updates that require a reboot to be fully applied.
After rebooting, my machine had a noticeable display lag, on everything from mouse movement to hardware-accelerated video playback on YouTube.
My first thought was that by updating my kernel I had inadvertently applied some update that did not agree with my system. In my experience, this is very, very rare on modern Linux distributions, especially Ubuntu, but with the recent Spectre / Meltdown patches, I figured it was still possible.
So, I began rolling back each package that had been updated, one by one. An hour or so later, and after an hour of cursing myself for not just installing NixOS already, I figured I had hit a dead end.
So I dove deeper. Two things were apparent: During the period of lag, Xorg was using about 30% of a core, which is very high for Xorg.
Inspecting the Xorg log in /var/log/Xorg.0.log revealed something curious. Hundreds of messages blocks like this;
As far as I can tell, when I moved my computer, the DVI connection between my GPU and my monitor became ever so slightly loose, in such a way that the GPU was detecting the monitor to become disconnected and reconnected about once per second. Even though there was no perceptible monitor flicker or “disconnected” messages, the process of disconnecting and reconnecting appears to have been consuming enough resources to delay frame rendering slightly every time it happened.
So, lesson for you - if you have display lag on a Linux system that you just can’t debug, maybe you just need to tighten your monitor connections.
This post is a set of notes on Bad Engineering Properties of Object-Oriented Languages” by Luca Cardelli, available at the time of writing from Cardelli’s site.
This post is mostly intended for my own notes. You may not find it useful.
First, Cardelli opens by defining 6 areas in which one can informally evaluate a language’s effectiveness for software engineering.
He then comments on some areas in which “advancements in procedural programming” have created positive changes in those six areas. Of particular note;
“In ML, accurate type information eliminates the need for nil-checking on pointer dereferencing”.
“… expereinced programmers adopt a coding style that causes some logical errors to show up as typechecking errors”
Cardelli then lists ways in which Object Oriented languages fail or score poorly on the metrics in question:
The first two points he lists, that object-oriented style is intrinsically less efficient and slower to compile, seem to be somewhat less relevant today than at the time of writing.
Cardelli argues that OO scores a “big win” in economy of small-scale development. Note that “The type systems of most object-oriented languages are not expressive enough.”
According to Cardelli, OO languages “have extremely poor modularity properties with respect to class extension and modification”. Note that another “large scale development problem” is the “confusion between classes and object types”, along with “the fact that subtype polymorphism is not good enough for expressing container classes”.
Cardelli then states where work is happening and what still needs to be done:
“Subtyping and subclassing must be separated. Similarly, classes and interfaces must be separated”
If you are developing AWS Lambda Functions, you will likely use AWS SAM Local
for running your functions in a local development environment.
AWS SAM Local is a great tool. However, many users, including myself, run into very
slow response times when first using AWS SAM Local, as documented in issue 134.
Simlpe functions may be taking more than 6 or even 10 seconds to evaluate.
This is likely for one of two reasons:
You are using a language with compiled-and-compressed code packages like Java’s JAR files.
You have not configured your AWS credentials.
For (A), AWS SAM Local unpacks your compressed code package on every request.
That process takes a few seconds, period. There are a few workarounds,
which include manually unzipping your .jar and pointing at the unzipped files
in your template.yaml’s CodeUri parameter.
However, if you are not using the C# or Java environments and are still experiencing slow requests,
you are in (B), and you can solve this problem by configuring your AWS Credentials.
indicates that you can provide credentials in one of two ways:
Specify AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables
Configuring a profile in ~/.aws/credentials for Linux or MacOs
Nota Bene: When AWS SAM Local’s README refers to ~/.aws/credentials, there is an implication
that you are using the AWS CLI v2, not the older v1, which stores information in ~/.aws/profile.
There are two gotchas with this documentation:
While both solutions will speed up execution, specifying the environment variables is noticeably faster.
I recommend you skip the AWS CLI configuration and just specify the environment variables.
If you put your credentials in ~/.aws/credentials in a profile, you need to specify --profile <profile_name
when you invoke sam for AWS SAM Local.
Note that for basic AWS SAM local operation, you do not need to specify valid AWS credentials - any old
value, even the empty string, will do!
Recently, I tried to get a development environment set up for developing
a single page web application ClojureScript - but with a backend written
to run on AWS Lambda functions, also in ClojureScript.
ClojureScript seems to use the Google Closure Compiler for compiling
import/export/require system that is different from Node’s module system.
Because AWS Lambda expects your JS to export the handler functions for the
Lambda function using the Node module system, I ended up with a real problem:
How do you require Google Closure-compiled ClojureScript into a node module?
The answer ended up being quite simple. Given that Closure is creating a compiled
file with name functions.js, which in turn is exporting a namespace functions.core,
you can create a new main.js file in the same directory as the compiled functions.js
file with the following content:
This took me longer than I care to admit to figure out, though that’s probably
thanks go to Matthew Stump’s post Writing NodeJS Modules in ClojureScript,
which had the trick as part of it.