Чтобы вы выбрали из этих двух вариантов:

1. лид в проекте встроенного ПО, с минимальным вовлечением в проектирование, разработку, но с серьезными техническими навыками, чтобы понять, где какие проблемы и как их решать (кого позвать/назначить их решать, кого с кем связать) или

2. принципал инженер ПО на задаче разработки очень ответственного корпоративного веб-сервиса? «Очень ответственного» не значит, что в п.1) какая-то никчемная поделка с низкой ценой ошибки, просто веб-сервис - не на от*еись, от которого многие команды как внутри конторы, так и со стороны заказчиков будут зависеть.

З/п, допустим, одинаковая. Но если кого-то рвёт от веб-сервисов, можно взять доп. вводную, что там будут платить больше. Принудиловки с технологиями (кровь из носа Java) в п.2) нет.

Можете задавать вопросы, если нужно больше инфы для принятия решения. Желательно также указать, почему.

Перемещено leave из job

Сегодня читал со смартфона новый (начало марта 2024г.) технический отчёт от гугловцев, в котором они объявляют о постепенном переходе на ЯП с memory safety. Сейчас не могу найти ссылку, но вот, что по сути.

Вводится таксономия ошибок при работе с памятью (типа пространственная и временная безопасность и проч.). Наверное уже миллион раз это уже предлагалось, и у Эппла есть аналогичная классификация. Для каждого типа ошибок предлагается решение.

Далее интересная штука. Ввиду того, что уже дофига кодовой базы на сишке и плюсах, переписывать это никто не будет, поэтому предлагается всё новое начинать на безопасных ЯП, а небезопасные подмножества использовать только для интерфейса с Легаси кодом, и привлекать к ревью небезопасного кода мощных экспертов.

Приводится какая-то статистика, что типа в Андроиде 70% критических уязвимостей - ошибки в работе с памятью. Но тогда возникает логичный вопрос, ведь кроме ядра в Андрюше очень мало плюсового кода, это какие-то нижние части HAL или что там у них, всякая околосистемная мишпуха, может быть кодеки какие анально огороженные, а всё что выше и остальное уже давным давно на память-безопасных мега языках. И что тогда переводить на эти безопасные языки, если всё, что можно уже и так переведено…

Предлагают типа тюнить плюсы до безопасного подмножества и использования только его. Но тогда нафига нужно будет с этого безопасного подмножества переписывать на Rust? Опять непонятка.

Упоминаются языки на VM, а также Rust, Carbon (экспериментальны проект, типа безопасный C++), Go (блин, он-то тут при чём, если это ниша веб-сервисов? Кто-то пишет вебсервисы на сишке, что это прямо такая глобальная проблема?). Ни слова о Аде. Видимо, упоминаются только те ЯП, в которые Гугл вложился и теперь пиарит.

Спрашиваешь у него чисто справочную инфу: сколько АПИ юнитов стоит скачивание видео. Он вываливает портянку, смысл которой в том, что типа, иди на х* (смотри справку по квотам АПИ). А в справке по квотам там никакого скачивания нет, и приходится опять таки прибегать к технологиям 90х, и гуглить о том, что скачивание не поддерживается АПИ.

Занавес.

https://lenta.ru/news/2024/02/15/v-rossii-zapustili-nabor-na-besplatnoe-obuchenie-v-it/

по 14 направлениям, среди которых разработка, машинное обучение, информационная безопасность и продуктовые исследования

 Лучшие студенты программ смогут претендовать на позиции в штате компании или приглашение на стажировку

Я бы пошёл, если бы начинал карьеру, ну там, людей посмотреть и себя показать. Интересно, на сколько там перекос в сторону Linux, ввиду событий последней пары лет.

В утекшей в сеть новой версии windows11 появилась знакомая всем пользователям Макос и Линукс команда sudo:

https://www.windowslatest.com/2024/02/01/first-look-windows-11-is-getting-native-macos-or-linux-like-sudo-command/

Предлагаю команде разрабов утилит в МС также добавить все линуксовые команды для полного юникс-вея, чтобы нативно и без всяких cygwin, и без всяких неюниксвейных пауэршеллов.

Рунет сегодня ожил, а тут свежачок подвезли:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6bd0e4efcc78f3c0115e5ea9739a1642807450da;hp=8aeec0eb5a18f9614d18156f9d6092b3525b818c

И ещё другие баги в glibc 2.37 типа порчи памяти в qsort.

Если бегло взглянуть на код исправления по ссылке, ясно, что это не что-то совсем уж тривиальное, т.е. именно те случаи, ради которых выдумываются и продвигаются все эти ады и расты. Но так же понятно, что в существенное количество устройств такие баги даже не смогут теоретически попасть, потому что будут исправлены ещё до того, как конторы дойдут до версии glibc 2022г.в.

Перемещено hobbit из talks

У меня десктоп на Ubuntu 22.04, ничего особенно не менял. Что конкретно отвалится или перестанет работать, если я сделаю systemctl disable snapd и перезагружу систему? Я так понял, файрфокс отвалится, т.е. его надо удалять из снапа и ставить из deb. Что ещё?

Ну что, любители меряться пиписьками, мозгами, пузами и проч., детище MS, легендарный ЯП С#, знаменитый своей AOT, стал языком 2023 года по версии TIOBE, с формулировкой " language with the biggest uptick in one year (+1.43%)".

https://www.tiobe.com/tiobe-index/#:~:text=January%20Headline%3A%20C%23%20is%20programming,Congratulations!

P.S. Ловсан должен быть доволен.

У кого-нибудь такое есть? Вернее, открывается апп с кнопкой затвора, но область захвата чёрная, и через пару секунд апп просто закрывается без каких-либо сообщений. Помогает только ребут.

Xiaomi POCO X4 pro g5.

Видел такое в одном проекте. Все *cpp располагаются в поддиректории impl, на один уровень ниже в дереве исходников относительно соответствующих заголовочных файлов.

Где это может быть удобно? Быстро скопировать заголовки и отдать кому-то без доступа к реализации? В любом случае всё тот же rsync, с минимальными отличиями. Автоматически добавлять ACL/MAC ограничения ко всем директориям impl? Что ещё?

Есть ли такие мышки, которые позволяют работать с разными BT адаптерами, переключаясь между ними?

Идея такая, чтобы воткнуть в разные компы по адаптеру, но мышку использовать одну, без всяких KVM свитчей.

Сабж дурацкий вопрос на собеседовании при устройстве на работу? или нет? Я к тому, что есть иногда такие критерии, как близость офиса к месту жительства (не всегда актуально для IT), репутация компании (что-то не слышал, что какой-нибудь мексиканский картель или иные бандосы занимаются разработкой ПО). На все остальные нюансы ответ один и тот же: думаю, что способствует моим карьерным/профессиональным интересам.

Я правильно понимаю, что китайский Loongson 3A6000 использует свою «совместимую с MIPS» архитектуру, и китайцы не должны ничего Wave Computing, и не ограничены лицензиями и проч.?

Пока SiFive реструктуризируется и увольняет сотрудников, MS работает над новым 128-ядерным ARM’ом для облаков. Целочисленная производительность ядра на уровне Ксеона эпохи SkyLake. Память планируется DDR5.

https://www.servethehome.com/microsoft-azure-cobalt-100-128-core-arm-neoverse-n2-cpu-launched/

Как думаете, что будет быстрее, собирать Линукс на младшей версии тредриппера в 64 потока или на вот этом, в 256?

Задумайтесь, почему люди, которые не застали эпоху 70х, 80х, с удовольствием смотрят фильмы того времени, а от современных плюются? Нельзя в данном случае сказать, что «когда я был молодой, солнце светило ярче, а стоял дольше», т.к. не было их даже в проекте, и никакого солнца для них не существовало.

Эпоха Вивальди и даже Моцарта - это вообще временной раздел размером с океан, и тем не менее.

Линукс тут при том, что когда копировали со «старых» коммерческих систем из 90х, была надежда, что будет альтернативный десктоп, а потом…

Разве это не подтверждение всеобщей дегенерации общества, а никакая не вкусовщина?

Все, кто занимается низкоуровневым жонглированием байтами в реалых промышленных условиях (с кучей поставщиков со всего мира, а не в уютненьком молодёжном стартапе где-нибудь в Саннивейл), понимают, что C’шка с нами надолго, лет на 20, если не больше. И поэтому возникает желание максимально использовать существующие технологии для обеспечения качества кода.

Например, Werror (и то, что к нему полагается в виде -Wall, -Wextra и проч.). Но возникают такие ситуации, как например с «целочисленным повышением» и последующим сравнением с разным знаком. Например:

const unsigned x = 12;
unsigned char y;
unsigned char z;
... // что-то кладём в y и z
if (x < (y*z))
{
   // тра-ля-ля
}

И y*z превращаются («брюки превращаются, превращаются брюки…») в элегантный int, и вылезает предупреждение о различной знаковости, как бы совершенно на ровном месте. Т.е. теперь, чтобы ублажить компилятор, надо дополнительно, например, явно кастануть x к int’у. Т.е., код уже на пределе читаемости (выше пример - это сильное упрощение возможной реальной ситуации), и тут мы ещё добавляем вовсе не интуитивный (int).

И возникает вопрос: а стоит ли овчинка (-Werror и ко.) выделки? Я сейчас, очевидно, не имею в виду код наивысшей критичности, а такой, который при случае можно просто неспеша поправить, в конце рабочего дня, с нулевыми последствиями для пользователей, окружающей среды и т.п.

P.S. кстати, поскольку в расте тоже есть беззнаковые типы, там тоже нечто подобное должно быть, или как?

UPD: в примере, в нагрузку к умножению надо ещё добавить сложение с ещё одним unsigned char.

В GNOME ввели уже давно какую-то наркоманскую хрень. Если в приложении выбрать «открыть файл», pop-up окно отрывается где-то на заднем плане, а на переднем появляется уведомление, что типа окно готово. Где настроить, чтобы по-человечески диалог показывался сразу после его открытия?

Джон Лакос выпустил аж три тома «Large-Scale C++». Кто-нибудь читал? Что скажете, стоит тратить на них время?

Допустим, окончили вы мега-курсы, и приходите устраиваться C++-программистом. Написали «C++» в списке знаний и навыков в резюме, и с гордо поднятой головой шагаете на интервью.

И вот, вам дают такой вопросик. Скажите, что произойдёт при выполнении данного кода (код, разумеется, бредовый, иначе как проверить знание секретов C++?):

#include <iostream>

struct T
{
    int iVal = 0;
    void printValue() const
    {
        std::cout << "Value is " << iVal << std::endl;
    }
    void destruct()
    {
        delete this;
    }
};

int main()
{
    T x{9};
    x.destruct();
    x.iVal = 11;
    x.printValue();
}

Какой правильный ответ, и почему?

Кто не знал, в C++23 добавили «монадические операции» для std::optional. Вот тут можно посмотреть пример:

https://www.cppstories.com/2023/monadic-optional-ops-cpp23/

Что бы вы предпочли в своем коде: первый вариант (по старинке с if(x) …) или второй, монадический? При условии, разумеется, что вам доступен и разрешен C++23.

Лично я - первый, и вот, почему:

1) во-первых, классический пример уже неоправданно многословен. Зачем писать «if (x) … if (! x) …», когда можно просто «if (x) … else …»;

2. автор как бы специально хочет показать, что с монадическими код короче, и специально вставляет пустые строки между if’ами, там где с монадическими операциями пишет всё подряд без пустых строк;
3. приходится на пустом месте создавать лямбды;
4. а что, если будет два std::optional, и второй используется опционально, при условии, что первый установлен? Тогда забор из лямбд.

Такое ощущение, что делается это всё ради жертвы богу функциональщины.

А вы как считаете?