Опустим тривиальные случаи типа EINTR.
Например, возвращается EIO - «An I/O error occurred», что не сильно более информативно, чем «иди на …».
Фактически, ничего дельного, кроме разве что отправки лога (или попапа об ошибке, если это гуишное ПО), сделать нельзя.
Можно попытаться повторить операцию close.
Но откуда мы знаем, что во второй раз она завершится удачно?
В общем случае она теоретически может завершиться удачно на (N+1)’й попытке, где N может быть произвольно большим числом.
UPD: а ещё не специфицировано, освободится ли дескриптор файла при EIO, так что в такой ситуации ещё может быть исчерпание лимита открытых файлов.
А вы что делаете в таких случаях, когда вообще непонятно, как программе обработать ошибочное состояние?
This approach generates the circuit logic, which is represented by a graph structure called Binary Speculation Diagram (BSD), of the CPU design from only external input-output observations instead of formal program code. During the generation of BSD, Monte Carlo-based expansion and the distance of Boolean functions are used to guarantee accuracy and efficiency, respectively. By efficiently exploring a search space of unprecedented size 10^{10^{540}}, which is the largest one of all machine-designed objects to our best knowledge, and thus pushing the limits of machine design, our approach generates an industrial-scale RISC-V CPU within only 5 hours. The taped-out CPU successfully runs the Linux operating system and performs comparably against the human-designed Intel 80486SX CPU.
Никогда такого не было, и вот, опять.
Оказалось, что реализация maple tree, которые добавили вместо rb tree для более отзывчивой рулёжки виртуальной памятью (в 6.1?), подвержена проблеме use-after-free.
Исследователи утверждают, что у них есть готовый эксплоит, который позволяет локальному пользователю повысить привилегии.
В соответствие с политикой выкладывания таких эксплоитов, опубликован код будет не ранее конца июля, но исправление уже смерджили.
Слышали новость? Какие-то богатые туристы залезли в батискаф, и решили погрузиться в океан, чуть ли не до Титаника. Ну и пропали без вести.
Как думаете, может ли на таком подводном корабле управляющая система быть основана на Linux? Ведь сейчас Linux куда только не пихают, во всяком случае, в машины точно, хотя бы в виде андроида. Какие технические проблемы в использовании Linux для целей подводного плавания?
Как считаете, это нормально от архитекта требовать:
The Software Architect will be expected to conduct root cause analysis on defects,
identify interim and permanent fixes
Понятно, что для каких-то нетривиальных багов нужна помощь всей команды технарей, но как понять, что у конторы просто нет программиста, и требуется «и швец, и жнец, и на дуде игрец»?
Или в наступившем мире нет больше фиксированных ролей в ПО-инженерии?
Можно как-то увеличить время видимости нотификации, которая появляется при подключении usb-диска? Пока я доставляю мышь, чтобы открыть корень, нотификация уже исчезает. KDE той версии, которая в KUbuntu 22.04.
Под эгидой The Linux Foundation собрались большие акулы (Intel, Samsung, Nvidia, Google, Qualcomm, RedHat) и будут выделять деньги, координировать дальнейшую разработку софта (llvm, gcc, linux, android, python, openjdk, openblas и др.).
RISE is dedicated to enabling a robust software ecosystem specifically for application processors that includes compilers, toolchains, system libraries, kernel, virtualization, programming languages, Linux distribution integration, and tools for debug and profiling.
Так что глядишь, лет через 5 очередной самсунговский смарт уже на RISC-V будет, а не на ARM. Ну а там и Apple подтянется, и «сделает всё, как следует».
Вопрос тем, кто использует (изначально, преимущественно) не функциональные ЯП (C++, Java, Python).
Как вы относитесь к CPS (Continuation-Passing Style)?
Для тех, кто не в курсе, например, есть некая операция, которая может завершиться удачно, а может с ошибкой, и вместо:
Result performOperation()
{
return doOperation();
}
...
Result result = performOperation();
if (OK == result)
{
std::cout << "OK" << std::endl;
}
else
{
std::cout << "NOK" << std::endl;
}
Вопрос админам и околоадминам. А так ли нужна была эта платная поддержка дистрибутивов типа RHEL, SuSE Enterprise (или как там его)? И теперь, в связи с прекращением ее на территории РФ, какие дистрибутивы использовать для серверов? Или всё пофиг, и всё то же самое, но без платной поддержки производителя?
Кто-нибудь с Убунтой 22.04 может такое проверить?
Речь о сетевом интерфейсе с 802.1x (можно проверить с USB-to-Ethernet адаптером).
У меня на 20.04 вот такое: Устанавливаю пароль, сохраняю его, выхожу (до этого 8021x security не был включен). Далее, захожу опять в настройки интерфейса, меняю пароль, жму «Apply». Захожу опять, смотрю пароль - не поменялся!
Никак не меняется пароль в NetworkManager. Только если удалить профиль и создать новый.
Гугл вводит новый механизм аутентификации в гугло-аккаунты, на замену паролям и двухфакторке. Называется Passphrase. Если правильно понял, просто вводится пин или биометрия, чтобы получить доступ к локальному ключе-хранилищу, а уже там ключ. Вроде, копировать это хранилище на другой комп бесполезно. Если смог разблокировать хранилище, Гугл считает, что ты тот, за кого себя выдаешь.
Пароли люди выбирают плохие, или поддаются на удильные атаки, а с помощью ИИ так вообще… А на второй фактор тоже существуют свои атаки.
Ничего нового особенно: 10-20 лет опыта работы на C++, 20+ общего опыта программирования, MSVC, десктопная винда, линукс, инженерия (авионика и проч.), ембеддед, исходники зависимостей - часть билда, напрягает менеджмент зависимостей и время сборки, большинство используют C++11.
Почему в Андрюше нет такого режима, как subj.?
Например, Я включаю Ютуб, но мне не нужно видео, а только аудио, и соотв. не нужен включенный экран, и в то же время, Я например кладу смарт в карман или в машине в кармашек, и я не хочу, чтобы случайно нажалась какая-то кнопка.
Или я включил навигацию, и хочу видеть всё, что она показывает на экране, но опять таки, не хочу, чтобы случайно нажалось место на экране, потому что иду по маршруту, смартфон то в руке, то в кармане, то в рюкзаке.
Отовсюду мы слышим стоны: C++ небезопасен! хватит использовать C++! АНБ призвало отказаться от C++, европейские законодатели готовят CRA, чтобы закрутить гайки для разработчиков небезопасного софта. Страуструп реагирует, вот его беседа о «Hardening C++»: https://youtu.be/eLLi0nWMUMs .
Начало:
Когда я задумал C++ в 1979г., я взял C за основу. У меня не было знаний, чтобы создать ЯП с нуля;
Я с самого начала всячески выступал за гораздо более строгую систему типов в C++;
Меня раздражает, когда люди говорят о каком-то C/C++, это мифический ЯП, его не существует;
Если мы говорим о безопасности, есть подмножество языка, которым можно ограничиться при написании безопасного софта. И тогда статические анализаторы типа clang-tidy или от MS позволят привести код довольно близко к виду «безопасный». Мы можем почти гарантировать, что в нем нет утечек памяти, болтающихся ссылок, и проч. Также можно опираться на безопасные библиотеки типа span, которые проверяют например границы доступа. И мы видем, что и другие ЯП прибегают к тем же мерам;
другия ЯП, которые утверждают, что они безопасные и у них нет небезопасного кода… если в них есть способ вызвать C или C++, они уже не безопасные;
Можно определить различные профили безопасности, которые определяют, какие фичи можно использовать, а какие - нет, чтобы избежать проблем, которые возникают из-за использования данных фич. Подобный подход используется в Ada. Но в принципе, это же делают статические анализаторы;
Мы пишем библиотеку поддержки GSL, в которой есть такие вещи как span, которые позволяют избежать проблем с указателями;
Если вы посмотрите на проблемный код, о котором все вопят, который приводит к проблемам, о которых вопят, это старый код, написанный в старом небезопасном стиле. Если посмотреть на то, как подобный код выглядит в новом стиле, этот новый код безопасен;
Необходимо запретить разрабам компиляторов использовать UB как предлог для оптимизации;
и т.д. и т.п.
Выглядит довольно слабо. С самого начала был выбран небезопасный C в качестве основы системы типов. Как можно «выступать за безопасную систему типов» в ЯП, в котором в центре небезопасное ядро? Почему бы не набраться смелости и не сказать «да, C++ не безопасен, и никогда не будет безопасным; безопасность я выбросил, потому не нужна была, да и не потянул бы». Потом прошло много времени, проблемы набирались, как снежный ком, и теперь, когда C++ в каждой дырке, они начали чесаться: ой, нам нужны профили, нам нужно запретить небезопасные фичи; нам нужно то, это, третье, десятое, но вот статические анализаторы, они же примерно и делают необходимые проверки…
Особенно смешно выглядит сравнение с Адой и ее профилями. Потому что стандартная Ада, без всех ограничений, качественно безопаснее C++, и дело не в «безопасных библиотеках», а в более продуманной с самого начала системе типов. Но Страуструп не зря ссылается на Аду, скорее всего, понимает, что есть с самого начала грамотно спроектированные ЯП, а есть C++.
Есть ли дистрибы Линукса кроме Федоры (ну и соотв. РэдХэт) на которых seLinux в режиме enforced работает из коробки? Или все кроме RH и ко на него забили в пользу apparmour или вообще без MAC? Пробовал врубить seLinux на убунте, вместо apparmour, и оно даже не загрузилось.
Не знаю, обсудили это на ЛОР уже или нет, но я только что узнал, что европейские законодатели решили сделать софт более безопасным по закону, введя требования к производителям софта по типу существующей маркировки CE для аппаратуры, но для софта, Чтобы призвoдитель сам удостоверился, что его продукт типа безопасен с т.з. программных уязвимостей и соблюдения приватности. Достигаться это должно при помощи всяких мер типа security by design и проч. А за небезопасный софт могут нехило штрафануть, в зависимости от того, какими суммами контора разработчика воротит, до 15млн евро или 2.5% годового оборота.
Называется оно Cyber Resilience Act.
Прикол в том, что сразу возбудились конторы OSI, PSF (питон), EclipseFoundation и проч., что якобы в текущей формулировке, даже несмотря на то, что опенсорс, вроде как исключен, документ так составлен, что можно привлечь опенсорс организации за баги в их продуктах. Т.е. вот есть например большой и толстый коммерческий проект, и в нем используется какая-то библиотека из PyPI, и с очередным апдейтом проприетарного софта тянется новая версия этой библиотеки, и если в этой новой версии есть новая уязвимость, то PSF якобы можно привлечь к ответственности за эту уязвимость. Даже несмотря на то, что разрабы той питоньей библиотеки не получают ни копейки от производителя коммерческого софта, и вообще никак не связаны с процессом разработки оного.
А вы как относитесь к обеспечению безопасности кода по закону?
Что, если пойти еще дальше, и автоматом вычитать из зарплаты программиста эти 2.5% («ведь GPT бы без ошибки написал»), или расширить штраф до тюремного срока? Ведь могут быть очень серьезные катастрофы, с многочисленными жертвами. Почему маньяки-убийцы тянут длинные сроки, а разработчики убийственного софта гуляют на свободе?
Четыре студента нашли уязвимость в приложении FreeHour, популярном в среде мальтийского студенчества, позволяющую просматривать личную инфу пользователей.
Как добропорядочные белошляпники, они сообщили о уязвимости CEO компании-разработчика.
Тот, в свою очередь, по его словам, следуя предписанию соотв. госоргана по борьбе с киберпреступностью, передал эту инфу «куда надо».
В итоге к скубентам вломилась полиция, изъяла все компы, а самих арестовала, на основании некоей статьи о «доступе к приложению без надлежащего разрешения уполномоченного лица».
И теперь им грозит штраф в $23К и срок 4 года.
Посоветовали мне тут в Development спросить свой вопрос у https://gpt-chatbot.ru/ .
Но я решил сначала проверить, а понимает ли вообще GPT что-то в программировании.
Спросл «Why is Ada programming language not popular?» .
И вот, что мне ответил ИИ:
As an AI language model I don't have opinions but here are some of the reasons why Ada programming language is not as popular as some other programming languages:
1) Lack of marketing - Ada is not as heavily promoted as some other programming languages, so it is not as well known.
2) Steep learning curve - Ada can be difficult for beginners to learn due to its complex syntax and strong typing rules.
3) Targeted audience - Ada was designed primarily for large-scale, mission-critical systems, which limits its application in other areas.
4) Limited resources - Due to its limited popularity, finding reliable online resources and support for Ada may be difficult.
5 ) Competition from other languages - Ada faces strong competition from other popular languages like Java, Python, and C++ which offer similar features and are more popular.
Government ties - Ada has been traditionally used by government institutions and organizations, which has limited its reach in the wider community.
со всем могу согласиться, но вот пункт 5) меня удивил. Все в одну кучу свалил, и коней, и людей. На счет C++ можно согласисься, и в области дженериков C++ ушел вперед. Java уже с натяжкой. А вот какие там в Питоне: объекты на стеке (а не в куче), многопоток из коробки, низкоуровневость вплоть до bare metal, отсутствие GC, автоматическая проверка указателей на null, числовые подтипы с лимитированной областью значений, и т.д. и т.п.
Ну это же просто разные миры!
Т.о. ощущение такое, что все остальные пункты оно просто подсмотрело где-то, по принципу кто-то что-то написал в инет, не особо понимая, что оно значит, а на пятом пункте полное непонимание вырвалось наружу, как субстанция из старой развалившейся канализационной трубы.