Кто нить пробовал? Это стоит апгрейда с 16.04

По профилю всего-всего 2.5 проекта, а свитчеров не рассматривают — и так кандидатов хватает.

Это описание П*ЦА в двух словах.

Ожидается что приложении будет написано на Kotlin для Android

Порекомендуйте ресурс для краудфандинга. Kickstarter и Indiegogo как ни странно не поддерживают мою страну (Польша).

А остальные, которые я встретил,— не поддерживают опенсорс.

Сферы вероятных проектов — солнечная энергетика и эргономика.

Благодаря КОВИД-у я снова в поиске работы :-(

Умею С, системное программирование, сетевое программирование, Embedded, ограничено — бэк-енды. Могу за несколько дней переключится на Java or Python. За недельку или чуть более Erlang, Perl или Kotlin.

Рассматриваю славянскую часть ЕС и южную Америку. Возможно — Канада и Корея.

https://www.youtube.com/channel/UC-XcQtgPzXBkl2xnXAhZTvA

Не то чтобы меня это напрягало, но видимо произошло что-то серьезное.

Проэкт свернулся из-за короновируса. Есть ли перспективы найти что нибуть до окончания п-ца?

ЗЫ: Знакомый сделал голосовалку в телеграме — 11% программеров уже без работы.

Подскажите в каком направлении копать?

Pthread_create() возвращает EAGAIN

Доступной рамы — over 32GB

Стек ограничен — 256 КБ.

/etc/sysctl.conf:

kernel.threads-max = 999999
vm.max_map_count=1999999
kernel.pid_max = 4194303

/etc/systemd/system.conf:

DefaultTasksMax=unlimited

/etc/systemd/logind.conf:

UserTasksMax=999999

/etc/security/limits.conf:

*         hard    nproc      500000
*         soft    nproc      500000
*         hard    nofile      500000
*         soft    nofile      500000
*         hard    sigpending  257543
*         soft    sigpending  257543

Коллега случайно открыл ssh наружу с символическим паролем

http://fanelishere.ro/arhive/

Требуется передача сообщений между контейнерами по подпискам. Очередь должна уметь асинхронные push-сообщения.

Суть — доступ к базе в event-loop при большом количестве входящих http соединений — over 30k.

event-loop подразумевается на базе libuv.

Пользуйтесь на здоровье. Лицензии CC + BSD.

https://github.com/vitalyvch/rng_buf

PS: А на новость случайно не потянет?

Я всегда пользовал cppcheck но вдруг появилось чтото лучшее?

Стандарты языка С предписывают компиляторам пользовать «быстрое» сравнение, вместо корректного.

То есть в следующем коде согласно всех стандартов языка С переменная res должна получить значение 0 а не 1, что крайне непрактично.

unsigned int a = 1;
int b = -1;
int res = (b < a);

Недавно я узнал что существует заметно больше способов корректного сравнения чем я изначально предполагал. Поэтому мне интересен чужой опыт.

Естественно речь о ситуациях где отказаться ни от знаковых, ни от беззнаковых никак нельзя.

Мой основной способ решения этой проблемы через расширение разрядности, так как я в первую очередь имею дело с unsigned char, но смесь size_t c ssize_t или что-то подобное также нередко доставляет неудобства.

Опишите кто и как выкручивается в сложившейся ситуации.

[UPDATE] ассемблерные листинги к классическим алгоритмам сравнения

For example x86 gcc 7.1 will for C++ source:

bool compare(int x, unsigned int y) {
    return (x < y); // "wrong" (will emit warning)
}

bool compare2(int x, unsigned int y) {
    return (x < 0 || static_cast<unsigned int>(x) < y);
}

bool compare3(int x, unsigned int y) {
    return static_cast<long long>(x) < static_cast<long long>(y);
}

Produce this assembly (godbolt live demo):

compare(int, unsigned int):
        cmp     edi, esi
        setb    al
        ret

compare2(int, unsigned int):
        mov     edx, edi
        shr     edx, 31
        cmp     edi, esi
        setb    al
        or      eax, edx
        ret

compare3(int, unsigned int):
        movsx   rdi, edi
        mov     esi, esi
        cmp     rdi, rsi
        setl    al
        ret

Взято вот здесь:

https://stackoverflow.com/a/44070807/73747

Естественно это все в контексте линукса.

Вопрос возник из того что указатель протягивается через много слоев API как void, и мне нужно убеждаться что тайпдеф и прототип/ф-я всегда консистентны.

У меня есть веские основания ожидать что такие мониторы будут создавать сильно меньшую нагрузку на глаза.

В связи с окончанием контракта, рассматриваю новые проэкты. Физически нахожусь - Польша, Гданьск. Командировки приемлемы ограничено.

Монитор предполагается иcпользовать в портретном режиме.

У меня сейчас на работе 24". Намного удобнее чем 22" до этого. Из этого собственно и возник вопрос - стоит ли сначала пробовать 27", или сразу идти на 30" или больше.