Статья хороша, почерпнул много доселе мне неизвестного.
На языке крутится вопрос: а есть ли у нас в стране хоть один ВУЗ, в котором обучают архитектурному проектированию ПО? В котором расскажут про подобные инструменты и потребуют в сдать в их формате лабораторные работы и написать с их помощью какой-нибудь курсовой проект? Или у нас учат только языкам программирования, а подобные знания черпаются уже потом из книг, спецкурсов и собственного опыта?
Мы это узнаем по факту, когда окажется что продукцию с нашим скрепным RISC-V мы не имеем права распространять на внешние рынки. И под санкции будут попадать страны, осмелившиеся купить эту продукцию. А внутри страны рынок окажется не таким емким, что бы поддерживать производство. И тогда снова начнутся вопли: что ж мы раньше об этом не подумали, наша электроника опять в дупле.
Можете показать место, где вы не поняли официальную доку?
Да пожалуйста: где там написано, что в Git сплошь и рядом идут ветвления без веток? Что в пределах одной ветки могут быть ветвления и это нормально? Новичек вообще не въежжает как такое может быть, хотя сталкивается с таким поведением сразу же как только над проектом начинают работать два человека или он сам один, но из разных рабочих мест. Нигде не найдешь внятного концептуального объяснения, что весь гит построен не на ветках, а на цепочках коммитов, и эти цепочки могут произвольно ветвиться и даже не иметь имен. Пользователь читает в доке одно, а по факту видит другое. И у него в голове не укладывается, что он делает неправильно, и что он недопонимает.
Нет, я посмотрел документы. В данном случае это только закупка оборудования. Никакого SLA там нет и быть не может, только гарантийные обязательства. Чтобы было SLA, нужен отдельный договор на оказание услуг. А по ссылке только поставка оборудования.
7М за сервер на Эльбрусе(-сах).
Нет, там в закупке не только сервера, но еще и сетевые коммутаторы, и KVM на 32 пользователя, и всякого другого барахла типа патчкордов, платформ СКЗИ и прочего приложено.
Мда, статья важная, но написана так, что вообще не приближает к пониманию как работает уязвимость Spectre, тем более на Эльбрусе.
У процессоров Эльбрус уязвимости Spectre нет на аппаратном уровне, но она проявляется на уровне компилятора.
Во-во, и понимай как хочешь. Чтение последующего текста говорит о том, что Spectre в Эльбрусах есть на аппаратном уровне, и проявляется она на уровнях оптимизации -O2 и -O3.
Макрос black_box используется для предотвращения оптимизации компилятором значения переменной.
О мой мозг. "Предотвращения оптимизации компилятором значения переменной" - что бы это значило? Почему бы не написать, что это стандартный хак, гарантирующий, что значение переменной, заданной в параметре макроса, будет обрабатываться остальным кодом в явном виде? Все переменные в коде, прошедшие через данный макрос, будут гарантированно существовать в результирующем машинном коде - никакая оптимизация не предвычислит значение на этапе компиляции, не уберет из кода как неиспользуемое, не развернет цикл если переменная управляет циклом.
Прочтя всю статью я так и не понял, что же происходит в процессоре, когда спекулятивно выполняются команды. И каким образом происходит считывание секретной строки. Наличие исходников не помогает, например там появляется такая сущность как кеш, но не поясняется что это такое - то ли это просто массив для хранения временных значений, то ли это аппаратный кеш процессора, толи еще что-то - объяснений нет. Автор смог выдать только:
происходит попытка считать байты из секретной строки, используя ранее определенные функции get_byte(), find()
И что? Автор сам-то понимает, что происходит в этих функциях? А почему он об этом не пишет?
Это достигается за счет измерения времени доступа к различным индексам в области памяти map, используя разницу во времени, чтобы определить, к какому байту был получен доступ во время спекулятивного выполнения.
Что скрывается за словами "к какому байту"? К какому байту по счету? Или к какому байту в смысле к какому значению байта? Как из времени получается значение, и почему это работает? Ведь это самое важное.
В общем, люди разучились внятно объяснять. И постоянно нужно клещами вытягивать: то ли автор все знает о чем говорит, но не может объяснить, то ли автор только делает вид что понимает о чем говорит, потому и объяснения у него бессмысленные. Есть еще третий вариант: автор ленив настолько, что не хочет стараться формулировать мысли, а свою лень скрывает за фразами типа "кто разбирается - тот поймет". Интересно, увижу ли я когда-нибудь автора, который и разбирается и внятно объяснять умеет? Или это фантастика?
В 2020 г. Счетная палата опубликовала отчет, согласно которому система "Мир" не в полной мере справлялась с поставленными перед ней задачами. Между ГС ПВДНП и ГС миграционного учета - двумя основными системами, из которых состоит "Мир", - электронное взаимодействие было "не всегда налажено". "На рабочих местах установлена система паспортов нового поколения, которая не связана с системой миграционного учета. Из-за этого сотрудникам приходится распечатывать анкеты на получение паспорта на бумаге и проверять их на другом рабочем месте, подключенном к системе миграционного учета. Затем сотрудник возвращается на свое основное рабочее место, чтобы вручную занести результат", - рассказывал аудитор Счетной палаты Алексей Каульбарс.
Какая дичь. Какой бред. У них две системы - "система паспортов нового, суко, поколения" и "система миграционного учета", которые "не связаны" друг с другом.
Первый вопрос - какого хрена система нового поколения не связана с другими рабочими системами? Кто проектировал, кто давал ТЗ, кто реализовывал, кто эту дичь принимал? Что им мешало сделать, что б было связано?
А второй вопрос - при чем здесь Эльбрус? Кто-то хочет протащить сказку что электронное взаимодействие было "не всегда налажено" из-за того что одна система на Эльбрусах, а другая - на x86? А вот теперь закупим Эльбрусы, и взаимодествие наладится? Так понимать?
Боже, как меня выбешивают эти интеграторы за сотни нефти. Больших вредителей имиджа отечественной электроники невозможно себе представить.
Статья неплохая, но написана так, как будто поменять ядро в Андроид - это обычное дело, никаких подробностей.
Я до сих пор не разобрался как рутануть свой POCO M4 Pro, потому что происходит остановка снятия защиты примерно на 50%, и интернет говорит что это ошибка сайта mi.com. И как другие разблокируют загрузчик - для меня загадка.
Но главное здесь - родитель/дочерний, для этого у них есть общий КуОбджект. Так что реальная иерархия тут только одна, восходящая к обджекту
Может я что-то не улавливаю, но менеджерам размещения вообще по барабану взаимоотношения родитель/дочерний QObject.
При конструировании формы, по сути создается своя собственная параллельная иерархия, которая отражает взаимосвязи на форме в формате "кто в кого вставлен".
Ибо: Когда новичек в Qt пытается осознать объектную иерархию конструкции, состоящей из основного виджета, менеджеров размещения (layouts) и подчиненных виджетов, ему легко сделать типичную ошибку: кажется, что основной виджет является родителем для менеджеров размещения, а менеджеры размещения являются родителями для подчиненных виджетов. На деле это не так
Когда дочерние виджеты "вставляются" в менеджер размещения через метод addWidget(), этот менеджер размещения не становится владельцем (т. е. родителем) дочерних виджетов. Он всего лишь знает о тех виджетах, которые в него "вставлены", и занимается только расстановкой этих виджетов на экране.
Но этого все равно недостаточно для безопасной работы с Git. Плюсуйте сюда разгребание логических нестыковок при слиянии кода, часто чужого, и вы поймете что в реальной жизни ситуации могут быть такими, что сам черт ногу сломит. Особенно когда программисты и руководитель проекта не понимают что короткие коммиты на одно изменение - это правильно. Тебе захреначат кучу изменений в одном коммите, а потом окажется что из этих изменений нужны только некоторые. И вот попробуй их разгреби если они в одном коммите лежат. А тебе будут говорить - зато история проекта короткая.
Я легко управлялся с CVS, потом легко переехал на SVN. Но когда появился Git - это было и остается каким-то кошмаром. Не помогают ни книги, ни документация, ни ублюдочные объяснения в стиле "машина времени Git" (кто это вообще придумал, совершенно не соответсвует парадигме Git).
Даже зная, что Git - это граф коммитов, а ветки - это указатели на коммиты, легче не становится. Мне потребовались годы, чтобы сформулировать следующую мысль:
Веткой в Git называется указатель на коммит, и этому указателю задано определенное имя. Если такой указатель указывает на последний коммит в цепочке, то в момент добавления нового коммита (у которого текущий является родителем) этот именованный указатель автоматически "переместится": то есть он начнет указывать на новый коммит. А имя указателя останется прежним. Таким образом, создается иллюзия, что программист работает в именованной ветке, и при добавлении коммитов ветка прирастает новыми коммитами. Хотя, на деле, система Git оперирует не ветками, а именно указателями на коммиты, не более того.
Нужно запомнить: никаких веток, в естественном человеческом понимании, в Git нет.
При этом во всех конторах я всегда был одним из немногих, кто разгребал сложные ситуации коллективной работы, другие просто вообще не въезжают что происходит, умеют только коммитить и выбирать ветки для работы. И каждую команду ввожу с боязнью что результат будет не тот который предполагал, а станет только еще сложнее распутывать весь клубок.
Слабоумие и отвага. Сколько можно наступать на одни и те же грабли?
RISC-V хоть и открытая архитектура, но лицензию предоставляет международный консорциум RISC-V, основанный в США, а значит, он обязана выполнять санкционные требования в отношении России, сообщил «Коммерсанту» эксперт среди разработчиков процессоров, сославшись на ситуацию 2022 года, когда Великобритания ограничила доступ к спецификациям архитектуры Arm, которую использовали последние процессоры «Байкал». Однако головная некоммерческая организация RISC-V International ещё в 2019 году «сменила прописку» на швейцарскую как раз из-за опасений возможных ограничений со стороны Вашингтона. В октябре 2023 года американские власти уже заявляли, что рассматривают возможность ограничить недружественным компаниям участие в международных сообществах RISC-V.
А у меня одного движок уровня записи неактивен, пока не нажмешь запись? То есть, чтобы выставить уровень, надо вначале нажать запись, потом крутить уровень. Это очень странно.
Да и кнопка остановки записи работает как-то вяло, несколько раз надо нажать чтобы запись остановилась, хотя казалось бы, в чем проблема остановить запись. То ли программа ждет наполнения какого-то буфера, то ли еще что.
Столько лет разрабатывать ПО, а косяки у него прямо на основных элементах управления годами не исправляются.
Статья хороша, почерпнул много доселе мне неизвестного.
На языке крутится вопрос: а есть ли у нас в стране хоть один ВУЗ, в котором обучают архитектурному проектированию ПО? В котором расскажут про подобные инструменты и потребуют в сдать в их формате лабораторные работы и написать с их помощью какой-нибудь курсовой проект? Или у нас учат только языкам программирования, а подобные знания черпаются уже потом из книг, спецкурсов и собственного опыта?
Как? Почему один бит?
В какой зависимости?
Какие возможны значения?
Как их обрабатывать?
Откуда заранее известен адрес?
Как он вычисляется?
Объяснение просто агонь.
И ни ответа, ни привета. Походу Otus занимается чисто спамерскими постами. Ясно, понятно.
Мы это узнаем по факту, когда окажется что продукцию с нашим скрепным RISC-V мы не имеем права распространять на внешние рынки. И под санкции будут попадать страны, осмелившиеся купить эту продукцию. А внутри страны рынок окажется не таким емким, что бы поддерживать производство. И тогда снова начнутся вопли: что ж мы раньше об этом не подумали, наша электроника опять в дупле.
Да пожалуйста: где там написано, что в Git сплошь и рядом идут ветвления без веток? Что в пределах одной ветки могут быть ветвления и это нормально? Новичек вообще не въежжает как такое может быть, хотя сталкивается с таким поведением сразу же как только над проектом начинают работать два человека или он сам один, но из разных рабочих мест. Нигде не найдешь внятного концептуального объяснения, что весь гит построен не на ветках, а на цепочках коммитов, и эти цепочки могут произвольно ветвиться и даже не иметь имен. Пользователь читает в доке одно, а по факту видит другое. И у него в голове не укладывается, что он делает неправильно, и что он недопонимает.
Нет, я посмотрел документы. В данном случае это только закупка оборудования. Никакого SLA там нет и быть не может, только гарантийные обязательства. Чтобы было SLA, нужен отдельный договор на оказание услуг. А по ссылке только поставка оборудования.
Нет, там в закупке не только сервера, но еще и сетевые коммутаторы, и KVM на 32 пользователя, и всякого другого барахла типа патчкордов, платформ СКЗИ и прочего приложено.
Мда, статья важная, но написана так, что вообще не приближает к пониманию как работает уязвимость Spectre, тем более на Эльбрусе.
Во-во, и понимай как хочешь. Чтение последующего текста говорит о том, что Spectre в Эльбрусах есть на аппаратном уровне, и проявляется она на уровнях оптимизации -O2 и -O3.
О мой мозг. "Предотвращения оптимизации компилятором значения переменной" - что бы это значило? Почему бы не написать, что это стандартный хак, гарантирующий, что значение переменной, заданной в параметре макроса, будет обрабатываться остальным кодом в явном виде? Все переменные в коде, прошедшие через данный макрос, будут гарантированно существовать в результирующем машинном коде - никакая оптимизация не предвычислит значение на этапе компиляции, не уберет из кода как неиспользуемое, не развернет цикл если переменная управляет циклом.
Прочтя всю статью я так и не понял, что же происходит в процессоре, когда спекулятивно выполняются команды. И каким образом происходит считывание секретной строки. Наличие исходников не помогает, например там появляется такая сущность как кеш, но не поясняется что это такое - то ли это просто массив для хранения временных значений, то ли это аппаратный кеш процессора, толи еще что-то - объяснений нет. Автор смог выдать только:
И что? Автор сам-то понимает, что происходит в этих функциях? А почему он об этом не пишет?
Что скрывается за словами "к какому байту"? К какому байту по счету? Или к какому байту в смысле к какому значению байта? Как из времени получается значение, и почему это работает? Ведь это самое важное.
В общем, люди разучились внятно объяснять. И постоянно нужно клещами вытягивать: то ли автор все знает о чем говорит, но не может объяснить, то ли автор только делает вид что понимает о чем говорит, потому и объяснения у него бессмысленные. Есть еще третий вариант: автор ленив настолько, что не хочет стараться формулировать мысли, а свою лень скрывает за фразами типа "кто разбирается - тот поймет". Интересно, увижу ли я когда-нибудь автора, который и разбирается и внятно объяснять умеет? Или это фантастика?
Какая дичь. Какой бред.
У них две системы - "система паспортов нового, суко, поколения" и "система миграционного учета", которые "не связаны" друг с другом.
Первый вопрос - какого хрена система нового поколения не связана с другими рабочими системами? Кто проектировал, кто давал ТЗ, кто реализовывал, кто эту дичь принимал? Что им мешало сделать, что б было связано?
А второй вопрос - при чем здесь Эльбрус? Кто-то хочет протащить сказку что электронное взаимодействие было "не всегда налажено" из-за того что одна система на Эльбрусах, а другая - на x86? А вот теперь закупим Эльбрусы, и взаимодествие наладится? Так понимать?
Боже, как меня выбешивают эти интеграторы за сотни нефти. Больших вредителей имиджа отечественной электроники невозможно себе представить.
Статья неплохая, но написана так, как будто поменять ядро в Андроид - это обычное дело, никаких подробностей.
Я до сих пор не разобрался как рутануть свой POCO M4 Pro, потому что происходит остановка снятия защиты примерно на 50%, и интернет говорит что это ошибка сайта mi.com. И как другие разблокируют загрузчик - для меня загадка.
Может я что-то не улавливаю, но менеджерам размещения вообще по барабану взаимоотношения родитель/дочерний QObject.
При конструировании формы, по сути создается своя собственная параллельная иерархия, которая отражает взаимосвязи на форме в формате "кто в кого вставлен".
Ибо: Когда новичек в Qt пытается осознать объектную иерархию конструкции, состоящей из основного виджета, менеджеров размещения (layouts) и подчиненных виджетов, ему легко сделать типичную ошибку: кажется, что основной виджет является родителем для менеджеров размещения, а менеджеры размещения являются родителями для подчиненных виджетов. На деле это не так
Когда дочерние виджеты "вставляются" в менеджер размещения через метод addWidget(), этот менеджер размещения не становится владельцем (т. е. родителем) дочерних виджетов. Он всего лишь знает о тех виджетах, которые в него "вставлены", и занимается только расстановкой этих виджетов на экране.
https://webhamster.ru/mytetrashare/index/mtb0/1628504234r3gp4s9cz9
Если указывает одна ветка, то есть однозначность. Можно было бы detached HEAD в этой ситуации и убирать.
Очень сомневаюсь. Я много лет назад писал статьи:
Git: как переключиться на нужный коммит и вернуться обратно? Понимание, что такое ветка
Не бойся хардресета! Он твой друг и помощник. (Как пользоваться git reset)
Но этого все равно недостаточно для безопасной работы с Git. Плюсуйте сюда разгребание логических нестыковок при слиянии кода, часто чужого, и вы поймете что в реальной жизни ситуации могут быть такими, что сам черт ногу сломит. Особенно когда программисты и руководитель проекта не понимают что короткие коммиты на одно изменение - это правильно. Тебе захреначат кучу изменений в одном коммите, а потом окажется что из этих изменений нужны только некоторые. И вот попробуй их разгреби если они в одном коммите лежат. А тебе будут говорить - зато история проекта короткая.
Конечно, они же эти стандарты контролируют. Даже Линуса заставили ранжировать комиттеров по признаку принадлежности к конкретно взятой стране.
Индустрии какой страны? Глобальных стандартов каких глобалистов?
Эх, надо было попробовать вместо модели манекен, и сделать это своей фишкой. О - оптимизация.
Я легко управлялся с CVS, потом легко переехал на SVN. Но когда появился Git - это было и остается каким-то кошмаром. Не помогают ни книги, ни документация, ни ублюдочные объяснения в стиле "машина времени Git" (кто это вообще придумал, совершенно не соответсвует парадигме Git).
Даже зная, что Git - это граф коммитов, а ветки - это указатели на коммиты, легче не становится. Мне потребовались годы, чтобы сформулировать следующую мысль:
При этом во всех конторах я всегда был одним из немногих, кто разгребал сложные ситуации коллективной работы, другие просто вообще не въезжают что происходит, умеют только коммитить и выбирать ветки для работы. И каждую команду ввожу с боязнью что результат будет не тот который предполагал, а станет только еще сложнее распутывать весь клубок.
В этой игре визуально можно понять, почему происходит отвал HEAD при элементарной команде "git checkout <хеш_коммита>"?
А игра покажет, почему git находится в разных состояниях при команде "git checkout <имя_ветки>" и "git checkout <хеш_последнего_коммита_в_ветке>?
На первой картинке сразу возникает непонятность.
Куда направлена ось времени? Вправо или влево?
Что означают стрелки? "Коммит произошел от" или "Указываю на следующий коммит"?
Слабоумие и отвага. Сколько можно наступать на одни и те же грабли?
RISC-V хоть и открытая архитектура, но лицензию предоставляет международный консорциум RISC-V, основанный в США, а значит, он обязана выполнять санкционные требования в отношении России, сообщил «Коммерсанту» эксперт среди разработчиков процессоров, сославшись на ситуацию 2022 года, когда Великобритания ограничила доступ к спецификациям архитектуры Arm, которую использовали последние процессоры «Байкал». Однако головная некоммерческая организация RISC-V International ещё в 2019 году «сменила прописку» на швейцарскую как раз из-за опасений возможных ограничений со стороны Вашингтона. В октябре 2023 года американские власти уже заявляли, что рассматривают возможность ограничить недружественным компаниям участие в международных сообществах RISC-V.
https://servernews.ru/1119297/
А у меня одного движок уровня записи неактивен, пока не нажмешь запись? То есть, чтобы выставить уровень, надо вначале нажать запись, потом крутить уровень. Это очень странно.
Да и кнопка остановки записи работает как-то вяло, несколько раз надо нажать чтобы запись остановилась, хотя казалось бы, в чем проблема остановить запись. То ли программа ждет наполнения какого-то буфера, то ли еще что.
Столько лет разрабатывать ПО, а косяки у него прямо на основных элементах управления годами не исправляются.