РКН головного мозга

Провайдер: ТТК (ТрансТелеКом)
     Цель: trello.com ... FAILED!
      WTF? http://help.trello.com/article/771-loading-resources-from-trellos-cdn
 Проверка: https://d78fikflryjgj.cloudfront.net/test.html ... FAILED!

    Магия:

  -- begin --
$ telnet d78fikflryjgj.cloudfront.net 443
Trying 54.192.98.126...
Trying 54.192.98.39...
Trying 54.192.98.107...
Trying 54.192.98.112...
Trying 54.192.98.253...
Trying 54.192.98.211...
Trying 54.192.98.106...
Trying 54.192.98.200...
telnet: Unable to connect to remote host: No route to host

$ sudo tcpdump -n -i eth1 icmp or host 54.192.98.39
... 188.43.30.130 > 10.0.0.2: ICMP host 54.192.98.39 unreachable

$ nslookup 188.43.30.130
... name = BlackList-gw.transtelecom.net.
  -- end --

      Диагноз: РКН головного мозга
Подтверждение: https://geektimes.ru/post/287418/#comment_9970944

Auto-generated headers in qmake project files

qmake is quite handy for simple source code layout but supporting non-standard use-cases within qmake boundaries is not trivial.

One such example is adding auto-generated header to your project. There are three items qmake must be made aware of before you get the expected and consistent results:

• arbitrary custom command for creating the header;
• dependencies;
• reverse dependencies from other files in the project.

The following snippet shows how to properly convert these items into the actual qmake syntax for "python gen-hdr.py > auto-gen.h" command which depends on a couple of extra files:

# This is a workaround to qmake bug (at least in 2.01a version) which
# results in invalid expansion of ${QMAKE_FILE_IN_PATH} variable within
# .commands definition in the presence of 'combine' .CONFIG option.
defineReplace(autoheadercmd) {
    LIST = $${1}
    return(python $$first(LIST) > $${2})
}

AUTOHEADER = gen-hdr.py hdr-template.py template-class.py
autohdr.CONFIG += combine
autohdr.input = AUTOHEADER
autohdr.output = auto-gen.h
autohdr.commands = ${QMAKE_FUNC_autoheadercmd}
autohdr.variable_out = HEADERS
QMAKE_EXTRA_COMPILERS = autohdr

This results in the following Makefile snippet:

compiler_autohdr_make_all: auto-gen.h
compiler_autohdr_clean:
    -$(DEL_FILE) auto-gen.h
auto-gen.h: gen-hdr.py \
        hdr-template.py \
        template-class.py
    python gen-hdr.py > auto-gen.h

or the following, in case of separate build directory:

compiler_autohdr_make_all: auto-gen.h
compiler_autohdr_clean:
 -$(DEL_FILE) auto-gen.h
auto-gen.h: ../gen-hdr.py \
  ../hdr-template.py \
  ../template-class.py
 python ../gen-hdr.py > auto-gen.h

Reverse dependencies are built automatically, and auto-gen.h will be properly listed where necessary in the Makefile, like this:

user.o: ../user.c ../user.h auto-gen.h
    $(CC) -c $(CFLAGS) $(INCPATH) -o user.o ../user.c

Correct reverse dependencies are especially important when using "make -j" for parallel compilation.

P.S.

See qmake: генерация файлов с помощью QMAKE_EXTRA_COMPILERS by Sergey Skoblikov for extra details, and its parent page - for various other qmake-related topics. (Both are in Russian.)

No Trust to X

Ctrl+Alt+<Keypad *>  - this is all you need nowadays to bypass screen lockers in X Server. Although, I believe, this flaw will be fixed pretty soon, the trust is lost for ever, and I'm going back to roots by switching to X-independent "vlock".

"sudo vlock -na" works even when called from X, and seems to be the most secure way to lock your machine, since virtual consoles are handled as well. 
 (Make sure you remember root password before executing the above command.)

Shell Poetry

If in script.sh you want to

echo err >/dev/stderr

then you should

echo err >>/dev/stderr

unless you plan to catch

only the last message

when running

script.sh 2>err.log

Forget all the above,

despite it works in many cases.

In fact, the only correct form is

echo err 1>&2

Beyond Brightness and Contrast

When you occasionally open advanced display properties on your PC you might notice there is a tab for controlling gamma parameters. I was always curious why gamma controls might be required and more importantly how to use them properly. Despite this fact I never had enough courage to get my teeth into the topic until today...

Leaving aside a boring story of what finally pushed me beyond brightness and contrast monitor controls I just want to promote an excellent tutorial by Norman Koren on monitor calibration and gamma.

Linux users might want to start with Monitor calibration under X article at linux.com which originally led me to the Norman's site.