Ting 이네 Software 이야기

I believe I can use "Function with closure" similar with "Class" even though it's definitely arguable that it's good practice.

아래 글은, 어떠한 논리적인 근거없이 작성된 개인적인 의견임을 먼저 명확히 명시합니다.

"부자 3대 못간다."라는 말이 있다. 비슷하게 회자되는 말로 "재벌 3세때 문제가 생긴다 - 3세 위기론"라고들 한다. 정말 그러한가? 잘 모르겠다. 첫 줄에 미리 언급한 바와 같이 어떠한 관련 근거도 찾아본 바 없다. 하지만, 그런 말들이 많이 회자 되는 것은 사실인 것 같다.
이 명제가 그럴 듯 하다고 가정하고, 이제부터 이유를 찾아 보려고 한다.

출처가 어딘지는 불문명하다, 이런 말을 들은 적이 있다. "창업주는 본인의 손으로 고생하면서 사업을 일으켰다. 2세는, 그 어려움을 보고 또 일부는 함께 하면서 자라서, 사업의 힘들고 어두운 면을 잘 안다. 하지만 3세는, 처음부터 안정적인 상태에서 큰 어려움 없이 자라서, 사업의 다양한 면을 알지 못하고 위기 대응 및 극복 능력이 떨어진다. 그래서 보통, 3세부터 문제가 생긴다."
어떤가? 설득력이 있게 들리는가? 물론, 이 말의 전제는, "창업주가 사업을 일으키고, 2세가 사업을 확장 및 안정시켜서, 3세에게 넘겨주는" 경우 - 사실 대한민국의 많은 재벌이 이 경우를 따른다 - 를 가정하고 있다. 나도, 이 말에 공감해 왔다. 하지만, 근래들어 새로운 관점이 생겨서 이에 대해서 이야기 하고자 한다.

먼저, 옛날 "군주"와 재벌의, 소위 "회장"은 어떠한 차이점이 있을까? 만약, 두 위치가 거의 비슷하다면, 어째서 "3세 위기론"을 옛 세습왕정국가에 적용하는 사례는 많지 않은가? 이 둘의 가장 큰 차이점은, "끊임없이 '왕좌'에 대한 위협이 존재하는가?" 라고 생각한다. 옛 왕국은 "장자세습"이 제도화 된 이후에도, 음모, 모략 등으로 인해 장자승계가 무난하지 않는 경우가 많았다. 승계서열 1위는 끊임없이 목숨의 위협을 느껴야 했다. 심지어 군주가 된 이후에도, 왕좌가 안정화 될때까지는 많은 시간이 소요되었다.
하지만, 현대 재벌들은 이러한 위협이 많지 않다. 목숨의 위협은 더더욱 없다. 특히 아들이 "하나"인 경우, 대부분의 경우 문제없이 승계가 이루어진다 - 대한민국의 경우, 지금은 많이 달라졌지만, 지금까지는 "남성", "장자" 우선 승계였다. 즉 위협 및 경쟁이 없다. 있다고 하더라도 아주 약하다. 난 이것이, 과거 "군주"와 현재 "회장"의 가장 큰 차이라고 생각한다. 그리고 이 차이가 "재벌의 수명"와 "왕국의 수명"의 차이 - 3세 위기론 - 를 만든다고 생각한다.

그럼, 구체적으로 이것이 어떠한 차이를 만들어내는 것일까? 앞서 이야기한, "어려움을 겪은 세대"와 "그렇지 않은 세대"의 차이일가? 좀 더 구체적으로, 이것이 무슨 차이를 만들어내는 것일까?
난, 이 모든 것에서 비롯된 "'사람 보는 눈'의 차이"가 근본적인 요인라고 생각한다. 어려움 없이, 처음부터 승계가 확정된 사람의 주위에는 다양한 종류의 인간 군상이 그 속내를 들어낼리가 없다. 사람은 관계가 변하면서 그 다면적인 모습을 드러내게 된다. 소위 "갑"을 대하는 "을"의 자세와, "을"을 대하는 "갑"의 자세는 다를 수 밖에 없다. 항상 "갑"의 위치에 있는 사람은 "을"일때 드러나는, 그 사람의 "단면"만을 보게 된다. 이것만으로 사람을 제대로 판단하는 것은 쉽지 않다.
앞서 이야기한 "어려움을 겪는" 다는 것은, 그 속에서, 다양한 역학관계를 가진 인적 네트워크를 경험하게 된다는 뜻이다. "갑"이 되었다가, "을"이 되기도 하고, 누군가를 믿어야만 하기도 하고, 배신을 경험하기도 한다. 이런 과정 속에서 믿고 신뢰할만한 사람을 찾게 되고, 사람을 보는 눈을 기르게 된다. 하지만, 항상 "절대 갑"의 위치에만 있었던 사람이라면 어떨까? 과연 그런 사람이 인간 군상의 다양한 면을 알고, 사람을 판단하는 "눈"을 가질 수 있을까?
결국 "군주"나 "회장"의 자리는 "사람을 쓰는 자리"이다. "인사가 만사"다. 물론 "의사결정"능력도 중요하지만, 본인이 모든 의사결정을 할 수는 없다. 때문에 "의사결정을 잘 할 수 있는 사람을 쓰는 일"이 가장 중요하다. 그런데 사람보는 눈이 없다면? 이것이 "3세 위기론"의 근본 문제라고 생각한다.

Let me share quite interesting observation.

Environment

• clang++: aarch64-linux-android34-clang++ of android NDK.
• Run on android device

Think about following project

a.cpp

namespace {
    std::map<std::string, int> m0_;
}
static std::map<std::string, int> m1_;

void noticeFromConstructor(const char *name, int value) {
    static std::map<std::string, int> m2_;
    m0_[name]  = value; // (*1)
    m1_[name]  = value; // (*2)
    m2_[name]  = value; // (*3)
}

b.cpp

namespace {
__attribute__((constructor)) void notify() {
    noticeFromConstructor("b", 1);
}

c.cpp

__attribute__((constructor)) static void notify() {
    noticeFromConstructor("c", 2);
}

SIGSEGV is signalled at both (1) and (2) when it run - from both b.cpp and c.cpp - but, (*3) is ok. I think it's because m0_ and m1_ are not initialized yet, but m2_ is initialized.
I'm not sure that there is any explicit description regarding initialization order for this case.

At early 2022, I used glib(2.66.x) for about 3 months for project run on OpenEmbedded Linux. Based on my short(3 months) experience, I would like review it. I mostly used gio and gdbus of glib. So, this review focus on those features.

Pros

• It seems that glib is very popular. However, I am not sure gio and gdbus are also as popular as glib.
• It has large set of features.
• It is easy to use in both C and C++.
• It supports multi-platform(Linux, Windows and so on).

Cons

• Lack of document. It was not easy for me to find useful documents and examples. Again, it's just my opinion. I think it may be caused from frequent changes of API.
• Some APIs doesn't give any response of error to caller. That is there is no way for caller to detect error happened inside API.
  • For instance, g_thread_pool_push() prints some error messages to stderr but doesn't return any error values to caller. I think it's because many APIs of glib provides very high-level functionality and use various techniques to improve performance and resource usage like memory pool, async operations and so on. However, it's very critical that there is no programmatic way for caller to detect error of API. I think it may be very critical defect when developers consider using glib at project requiring high-level stability like system daemon.
• Behavior of Linux file descriptor seems not intuitive to me. One of reasons may be glib provides unified API for multi-platform. For instance, in case of giving and taking file descriptor via GDBus, even if receiver receives only one file descriptor, sometimes, two new open file descriptors are created.
  • When using org.freedesktop.login1.Manager.Inhibit, even if only one file descriptor is passed via GD-Bus, two new file descriptor are created at /proc/<pid>/fd. So, even if FD(File Descriptor) passed via GD-Bus is closed, due to another open FD, inhibitor cannot be closed.
  • Same scinario work well as expected if sd-bus is used instead of GD-Bus.

Summary

After winning over lack of document and get used to it, it looks very powerful and useful library. However, as mentioned above, due to some APIs that don't give error response, it's usablity may be limitted at domain asking very high-level stability.

The title says it all (surprisingly).

This is my test.

Test source code - a.c

#include <stdio.h>


int main() {
    int a = 0;
    printf("%d\n", 1 / a);
    printf("Done\n");
    return 0;
}

Build it for x64 (ubuntu 22.04).

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:    22.04
Codename:    jammy

$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

$ gcc a.c
$ ./a.out
Floating point exception (core dumped)

However, built it for aarch64 with android-ndk toolchain.

$ android/ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android33-clang a.c
$ adb push a.out /data/a.out
$ adb shell /data/a.out
0
Done

No error! Just gives ZERO!!

You can get depth image at OpenGL or Vulkan. This article assumes VK_FORMAT_D32_SFLOAT of Vulkan is used as format of depth buffer..
In this case, pixel value of depth image is z-value at NDC space. So, you can reconstruct it's position in world space by using inverse of transformation matrix including perspective matrix.
Then, how can you get this depth image at Blender?
First of all, to get depth value at Blender, you have to make Output-File-Node of OpenEXR image format, and connect it to Depth (or Z) attribute.
But, value stored in this image is not depth(Z) value in NDC space. It's depth value at your view space. So, it's good practice clamping value between near-Z and far-Z.
That is value is between near-Z and far-Z. To get real z-value in NDC space, you can use your projection matrix(usually perspective matrix).
You don't need to know (x, y) value corresponding to this depth value - you can easily capture this by having a look perspective matrix multiplication.
In summary, you have to follow below steps.
- Getting OpenEXR depth image of view space at Blender.
- Convert it by using projection matrix to get depth value at NDC space.

    : You can use even Python: cv2, struct.(un)pack, torchvision, PIL and so on.

- Use (u,v) value and depth value of image to reconstruct position in view space.

This is not a topic of Linux kernel. I would like to introduce one of popular way protecting Policy file for SELinux that used in lots of linux(including embedded linux) system.

systemd is widely user process that is widely used as init process at Linux in these days. systemd loads SELinux data from SELinux root directoy (/etc/selinux by default) if SELinux is enabled, at very early stage. And then services registered are started.

Here is sample mount status.

...(skip)...
overlay on /etc type overlay (rw,relatime,rootcontext=system_u:object_r:etc_t:s0,seclabel,lowerdir=/etc,upperdir=/overlay/etc,workdir=/overlay/.etc-work,x-systemd.automount)
...(skip)...

And you can easily find systemd service doing this mount task.

According to steps of systemd, policy of SELinux is loaded before /etc/ is hidden behind by overlay filesystem. So, original SELinux data can be safely protected from users.

This way is very popular way protecting original data from users. You can apply this trick to various cases for your system.

개요

벌써 좀 오래전 일이긴 하나, 경험의 기록 차원에서 남겨 둔다.

진행 환경

• 팀: 기획을 주도하는 사람 한명을 중심으로, 전부 완전히 수평적인 관계의 5명 (나이도 비슷).
• 프로젝트: 대략적인 방향에 대해서만 동의된 상황에서 1년간 진행.
• 상황: 프로젝트 성공 여부에 따라서, 인사 평가가 결정.

진행

초기

• 프로젝트 진행방향을 구체화하는 과정에서, 서로 의견충돌이 발생.
• 의사결정권자가 없으므로, 의견충돌이 중재되기 힘듦.
• 어느 정도 서로 감정을 건드리는 상황도 종종 발생.

중기

• 서로 의견충돌이 발생할 만한 종류의 이야기는 언급을 피함. 그러다 보니, 중요한 의사결정이 제대로 내려지지 않음.
• 기획방향에 동의하지 않는 사람은 업무에 적극적으로 참여하지 않음.
• 생산성에 비효율이 발생.

말기

• 프로젝트 결과물이 기대에 미치지 못함.

요약

• 책임과 권한이 비슷한 여러사람이 이끄는 조직을 성공시키는 것은 쉽지않다. 이것이 일한사람이 이끄는 조직보다 더 나은지 아닌지는 모르겠으나, 고려해야할 사항이 좀더 많아 보인다.
• 한명이 의사결정권(책임과 권한)을 가지는 형태의 조직이 일반적으로 사용되는 것은 이러한 경험의 축적에서 비롯된 것으로 생각된다.

Test environment: Node 12.18.2 on Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

const SZ = 99999999


const l2a = [];
for (let i = 0; i < 10000; i++) {
    const sub = [];
    for (let j = 0; j < 10000; j++) {
        sub.push(j);
    }
    l2a.push(sub);
}

let s = new Set();
let t = -Date.now();
for (const a of l2a) {
    for (const n of a) {
        s.add(n);
    }
}
t += Date.now();
console.log('Takes: ', t);

const ta = [];
t = -Date.now();
for (const a of l2a) {
    ta.concat(...a);
}
s = new Set(ta);
t += Date.now();
console.log('Takes: ', t);

Result is

Takes:  3070
Takes:  1665

Concating and expanding array are very fast comparing to calling a function(Set.add).

NOTE: I observed it rxjs 5.5.12, 6.5.4, 6.5.5.

You may think that below two codes gives same results where s0 and s1 are instances of BehaviorSubject.

Code-1

s1.pipe(
    withLatestFrom(s0)
).subscribe(([v1, v0]) => {
    console.log(v0, v1);
});

Code-2

s1.subscribe(v1 => {
    s0.pipe(take(1)).subscribe(v0 => {
        console.log(v0, v1);
    });
});

In general case, it's true. But, in very unique situation, these gives different results.
Here is test code for it.

const s0 = new BehaviorSubject('A');
const s1 = new BehaviorSubject('a');

setTimeout(() => s0.next('B'), 500);

let i = 0;
s0.pipe( /* Part-A */
    withLatestFrom(s1)
).subscribe(([v0, v1]) => {
    console.log('s0-pipe: ', v0, v1);
    s1.next(++i);
});

s1.pipe(
    withLatestFrom(s0)
).subscribe(([v1, v0]) => {
    console.log('s1-pipe: ', v0, v1);
});

s1.subscribe(v1 => {
    s0.pipe(take(1)).subscribe(v0 => {
        console.log('s1-sub: ', v0, v1);
    });
});

This gives following result.

s0-pipe:  A a
s1-pipe:  A 1
s1-sub:  A 1
s0-pipe:  B 1
s1-pipe:  A 2  <=
s1-sub:  B 2

Two very interesting results are observed. s1-pipe: A a and s1-sub: A a are not shown. And s0 value at second s1-pipe is not latest one!

To avoid this, I used below workaround at code Part-A.

s0.pipe(
    withLatestFrom(s1)
).subscribe(([v0, v1]) => {
    console.log('s0-pipe: ', v0, v1);
    setTimeout(() => s1.next(++i));
});

Then, it gives

s0-pipe:  A a
s1-pipe:  A a  <=
s1-sub:  A a  <=
s1-pipe:  A 1
s1-sub:  A 1
s0-pipe:  B 1
s1-pipe:  B 2  <=
s1-sub:  B 2

I think it's design of rxjs. One thing I can learn from above is that it's very risky using circular withLatestFrom at rxjs.