В рантайм протащить это было бы сложновато. Как технически, так и организационно. Во‐первых, у Rust в runtime просто нет такой кучи информации, которую можно получить в той же Java, если её туда специально не добавит компилятор. Я примерно представляю, как это «специально добавит» должно выглядеть и оно содержит множество принципиальных проблем и вообще непросто в реализации.
Во‐вторых, пока даже на простенькие форматные строки с произвольными выражениями RFC не собрали — а там из проблем по сути только «как экранировать» и «а оно точно нужно?». Предложение вида «давайте потратим несколько человекомесяцев, чтобы получить в std свой собственный log4shell», конечно же найдёт широкую поддержку у разработчиков и сообщества.
Более ограниченный вариант вида «пользователь должен сам собрать словарь со всеми переменными, которые он хочет сделать доступными» ещё может появится в std и наверняка в каком‐то виде уже есть в крейтах. Но это не особо опасно.
Я с Элитана тоже до сих пор получаю 0603 резисторы маркированными. Правда, YAGEO на резисторах вместо стандартной маркировки NME (в смысле NM×10^E Ω) вполне может написать что‐то другое: точно сейчас не скажу, но было что‐то вроде 085 вместо 102, и так примерно на четырёх номиналах из 48 (но маркировки везде разные).
Зачем сейчас писать на ЯА? Когда-то это позволяло заметно ускорить программу. Но сейчас современные компиляторы настолько хорошо оптимизируют, что ускорения от ручного кодинга на ЯА не получается. (Конечно, если такое хобби, то понятно. В списке Tiobe и ЯП Brainfuck есть ;)
Помимо оптимизаций есть ещё и куча «специальных» применений. У меня, к примеру, по сути embedded разработка, со своей спецификой. Попробуйте объяснить компилятору хотя бы C, что часть регистров общего назначения должна быть зарезервирована под volatile память с глобальными переменными, в которой я буду смотреть наличие одиночных сбоев. Ещё мне обычно проще написать на ассемблере, чем выяснить, что не так в программе на C (или компиляторе), что она не работает или работает медленно: выяснение всё равно потребует понимания ассемблерного кода.
У меня Excel как‐то умудрился сохранить файл с большинством формул в локализованном виде. А потом при открытии эти формулы просто выкидывал (правда, не молча, а утверждая, что файл повреждён). LibreOffice при этом ничего не выкидывал, но и формулы не считал. Проблема решилась нахождением последней рабочей версии в СКВ, сравнении текущей с ней в распакованном виде (после LibreOffice мне стало только понятно, что формулы там есть, а не что с ними не так) и делокализацией скриптами на VimL с последующей запаковкой обратно.
И я не помню, чтобы я обновлял в это время Office, или трогал связанные с локализацей настройки.
Я что‐то подобное делал для Word. Там макросы хранятся в бинарном файле, имитирующем файловую систему (OLE2), который много кто умеет разбирать, но мало кто умеет создавать. Я в итоге просто решил хранить документ без макросов в распакованном виде в VCS, отдельно там же хранить макросы и скриптом запаковывать файл обратно с последующим добавлением файлов с макросами посредством API Word.
PS: Кто-нибудь знает, на хабре еще осталась простая возможность указывать индексы, как ранее было корректно: H2O ?
На помощь может придти Unicode: там есть вещи вроде U+2082 Subscript two: H₂O. И у меня ещё старый интерфейс, если предпросмотр не отличается от реальности, то в цитате нижний индекс вместо тегов.
Вычисления производились с использованием 80-битных числе с плавающей запятой (тип long double). Результаты аппроксимации сравнивались со значением синуса, полученными стандартной функцией sinl() из библиотеки С компилятора gcc.
Мне вот интересно, почему ещё никто не прицепился к этой части? В стандарте по поводу этой функции сказано только, что она вычисляет синус, никаких требований к точности не предъявляется. А функция ведь будет сама использовать какую‐то аппроксимацию, а не вызывать особую компьютерную магию, чтобы в выходном регистре появилось настолько точное значение синуса, насколько это позволяет формат long double. Так что не хватает исследования точности sinl.
И, кстати, при чём тут gcc? sinl лежит в libm, а libm согласно моему пакетному менеджеру, относится к пакету glibc.
Тут может программа виновата: к примеру, обычно предупреждает о необходимости перезаливки, а тут нет.
Мне как‐то Резонит КЗ поправил: когда я подвинул группу компонентов с проводниками и поправил КЗ на внешних слоях из‐за наехавших на неподвинутые проводников на небольшом количестве проводников во внутренних слоях КЗ остался. Что интересно, при проведении DRC ошибок не было (Altium). Узнал о том, что КЗ вообще был, когда было нужно поменять плату позже.
Сейчас часто да, но control там появился задолго до того, как я начал (на новой работе) в основном пользоваться LabVIEW и разными САПР и, соответственно, чаще держать правую руку на мышке. Просто правый control слишком далеко, чтобы нажимать его вообще. Когда я выбирал раскладку я в основном набирал разные opensource программы.
Я на caps lock назначил левый control, на левый control — escape, а сам caps lock поставил на escape (и использую его только чтобы отменить случайно произведённое нажатие на caps lock…). Учитывая, что control часто используется в разных сочетаниях клавиш, не понимаю, почему на место caps lock обычно ставят что угодно, но не его; по‐моему, всегда лучше вместо этого «что угодно» поставить на место левого control — у меня это escape, потому как я часто использую Vim. (А вместо backspace в Vim можно использовать <C-h>.)
Кстати, на escape в таком варианте можно при желании нажимать не пальцем (на клавишу‐модификатор так особо не понажимаешь, поскольку она нажимается вместе с чем‐то ещё).
От «ограниченного числа лиц» тоже нужно защищаться. Конечно, чтобы воспользоваться, к примеру, локальным повышением привилегий злоумышленнику потребуется больше ресурсов, чем если бы у него была возможность использовать удалённое выполнение кода. Но представьте, что без закладки условная «уборщица» может просто бессильно постучать по клавиатуре, а с ней — войти как администратор, тогда злоумышленнику будет достаточно в «ограниченном числе лиц» скомпроментировать «уборщицу», а не кого‐нибудь рангом повыше.
Так я вообще‐то отвечал, что можно усмотреть на кристалле с небольшими проектными нормами, а не как защищать схемы в принципе. Разумеется, другие векторы атаки требуют других методов защиты. Но визуальная проверка кристалла всё равно сделает внедрение на производстве слишком дорогим, чтобы этим кто‐то занимался.
Невозможно что? Детально посмотреть топологию — нет, нельзя. Убедиться, что у кристалла нет чего‐то, напоминающего массив памяти или ещё чего в месте, куда его не ставили, а то, что есть, выглядит как то, что должно быть — можно. Если такой проверки нет, то кто‐нибудь может и рискнуть: стоимость разработки кристалла с закладкой может и высока, но не заоблачна. А вот стоимость разработки кристалла с закладкой такой, что её нельзя обнаружить по сути визуальной проверкой, да ещё и в сжатые сроки (разработки, не проверки) — это как раз почему закладок быть не может.
Аккуратности ради: моргать можно любым диодом, равно как и принимать свет. Просто какие‐то оптимизированы на излучение, какие‐то на регистрацию, а какие‐то предназначены для чего‐то ещё.
Я очень сильно сомневаюсь что российские инженеры способны хотя бы проверить призведеное железое в Китае, ибо они бы могли тогда проверить уже любые готовые процессоры.
Нет, не могли бы. Проверить своё, значит проверить, что кристалл на выходе соответствует топологии, которую сделали свои инженеры на основе своего HDL кода. Проверить чужое при том, что детали топологии и HDL код неизвестны — значит взять кристалл, определить какие там элементы и с чем соединяются (нужны очень дорогие микроскопы с современными нормами), на основе этого отреверсить HDL код и в этом коде (который будет читаться не лучше результатов декомпиляции обычных программ) попытаться найти закладку. Учтите ещё и то, что даже если тот же Intel нам выдаст всё, что у него есть по своим процессорам, грамотно замаскированную закладку могут всё равно не найти.
Другими словами, для такой проверки нужно более дорогое оборудование и инженеры с весьма специфическими квалификациями.
Вообще‐то не совсем так: для того, чтобы у земли был радиус ей достаточно всего лишь иметь точную верхнюю грань всевозможных расстояний между её точками. Впрочем, я не удивлюсь, если кто‐то утверждает, что земля плоская и бесконечная.
И много у вас такой информации, которой вы готовы поделится, которую вы не забудете (особенно лет через 10) и которую нельзя подобрать по словарю, с учётом того, что вы не должны использовать один и тот же ответ на разных сервисах по тем же причинам, по которым вы не должны использовать один и тот же пароль?
Я всегда считал, что контрольный вопрос — это второй пароль. Если я не собираюсь забывать первый, то он не нужен, а если я не хочу, чтобы смог войти злоумышленник, то контрольный вопрос должен быть так же надёжен. Поэтому там обычно случайная строка символов, которую я нигде не сохранил.
Кстати, автор не прав и там можно отправить запрос в поддержку: «не могу войти в аккаунт» — «не помню пароль» — «у меня не получилось восстановить пароль самостоятельно» — «написать в службу поддержки», тогда откроется форма.
В рантайм протащить это было бы сложновато. Как технически, так и организационно. Во‐первых, у Rust в runtime просто нет такой кучи информации, которую можно получить в той же Java, если её туда специально не добавит компилятор. Я примерно представляю, как это «специально добавит» должно выглядеть и оно содержит множество принципиальных проблем и вообще непросто в реализации.
Во‐вторых, пока даже на простенькие форматные строки с произвольными выражениями RFC не собрали — а там из проблем по сути только «как экранировать» и «а оно точно нужно?». Предложение вида «давайте потратим несколько человекомесяцев, чтобы получить в std свой собственный log4shell», конечно же найдёт широкую поддержку у разработчиков и сообщества.
Более ограниченный вариант вида «пользователь должен сам собрать словарь со всеми переменными, которые он хочет сделать доступными» ещё может появится в std и наверняка в каком‐то виде уже есть в крейтах. Но это не особо опасно.
Я с Элитана тоже до сих пор получаю 0603 резисторы маркированными. Правда, YAGEO на резисторах вместо стандартной маркировки NME (в смысле NM×10^E Ω) вполне может написать что‐то другое: точно сейчас не скажу, но было что‐то вроде 085 вместо 102, и так примерно на четырёх номиналах из 48 (но маркировки везде разные).
Помимо оптимизаций есть ещё и куча «специальных» применений. У меня, к примеру, по сути embedded разработка, со своей спецификой. Попробуйте объяснить компилятору хотя бы C, что часть регистров общего назначения должна быть зарезервирована под volatile память с глобальными переменными, в которой я буду смотреть наличие одиночных сбоев. Ещё мне обычно проще написать на ассемблере, чем выяснить, что не так в программе на C (или компиляторе), что она не работает или работает медленно: выяснение всё равно потребует понимания ассемблерного кода.
Я так понял, технику безопасности сейчас должен рассказывать работодатель — тем, кто до него дожил.
У меня Excel как‐то умудрился сохранить файл с большинством формул в локализованном виде. А потом при открытии эти формулы просто выкидывал (правда, не молча, а утверждая, что файл повреждён). LibreOffice при этом ничего не выкидывал, но и формулы не считал. Проблема решилась нахождением последней рабочей версии в СКВ, сравнении текущей с ней в распакованном виде (после LibreOffice мне стало только понятно, что формулы там есть, а не что с ними не так) и делокализацией скриптами на VimL с последующей запаковкой обратно.
И я не помню, чтобы я обновлял в это время Office, или трогал связанные с локализацей настройки.
Я что‐то подобное делал для Word. Там макросы хранятся в бинарном файле, имитирующем файловую систему (OLE2), который много кто умеет разбирать, но мало кто умеет создавать. Я в итоге просто решил хранить документ без макросов в распакованном виде в VCS, отдельно там же хранить макросы и скриптом запаковывать файл обратно с последующим добавлением файлов с макросами посредством API Word.
На помощь может придти Unicode: там есть вещи вроде U+2082 Subscript two: H₂O. И у меня ещё старый интерфейс, если предпросмотр не отличается от реальности, то в цитате нижний индекс вместо тегов.
Мне вот интересно, почему ещё никто не прицепился к этой части? В стандарте по поводу этой функции сказано только, что она вычисляет синус, никаких требований к точности не предъявляется. А функция ведь будет сама использовать какую‐то аппроксимацию, а не вызывать особую компьютерную магию, чтобы в выходном регистре появилось настолько точное значение синуса, насколько это позволяет формат long double. Так что не хватает исследования точности sinl.
И, кстати, при чём тут gcc? sinl лежит в libm, а libm согласно моему пакетному менеджеру, относится к пакету glibc.
Тут может программа виновата: к примеру, обычно предупреждает о необходимости перезаливки, а тут нет.
Мне как‐то Резонит КЗ поправил: когда я подвинул группу компонентов с проводниками и поправил КЗ на внешних слоях из‐за наехавших на неподвинутые проводников на небольшом количестве проводников во внутренних слоях КЗ остался. Что интересно, при проведении DRC ошибок не было (Altium). Узнал о том, что КЗ вообще был, когда было нужно поменять плату позже.
Сейчас часто да, но control там появился задолго до того, как я начал (на новой работе) в основном пользоваться LabVIEW и разными САПР и, соответственно, чаще держать правую руку на мышке. Просто правый control слишком далеко, чтобы нажимать его вообще. Когда я выбирал раскладку я в основном набирал разные opensource программы.
Я на caps lock назначил левый control, на левый control — escape, а сам caps lock поставил на escape (и использую его только чтобы отменить случайно произведённое нажатие на caps lock…). Учитывая, что control часто используется в разных сочетаниях клавиш, не понимаю, почему на место caps lock обычно ставят что угодно, но не его; по‐моему, всегда лучше вместо этого «что угодно» поставить на место левого control — у меня это escape, потому как я часто использую Vim. (А вместо backspace в Vim можно использовать <C-h>.)
Кстати, на escape в таком варианте можно при желании нажимать не пальцем (на клавишу‐модификатор так особо не понажимаешь, поскольку она нажимается вместе с чем‐то ещё).
От «ограниченного числа лиц» тоже нужно защищаться. Конечно, чтобы воспользоваться, к примеру, локальным повышением привилегий злоумышленнику потребуется больше ресурсов, чем если бы у него была возможность использовать удалённое выполнение кода. Но представьте, что без закладки условная «уборщица» может просто бессильно постучать по клавиатуре, а с ней — войти как администратор, тогда злоумышленнику будет достаточно в «ограниченном числе лиц» скомпроментировать «уборщицу», а не кого‐нибудь рангом повыше.
Так я вообще‐то отвечал, что можно усмотреть на кристалле с небольшими проектными нормами, а не как защищать схемы в принципе. Разумеется, другие векторы атаки требуют других методов защиты. Но визуальная проверка кристалла всё равно сделает внедрение на производстве слишком дорогим, чтобы этим кто‐то занимался.
Невозможно что? Детально посмотреть топологию — нет, нельзя. Убедиться, что у кристалла нет чего‐то, напоминающего массив памяти или ещё чего в месте, куда его не ставили, а то, что есть, выглядит как то, что должно быть — можно. Если такой проверки нет, то кто‐нибудь может и рискнуть: стоимость разработки кристалла с закладкой может и высока, но не заоблачна. А вот стоимость разработки кристалла с закладкой такой, что её нельзя обнаружить по сути визуальной проверкой, да ещё и в сжатые сроки (разработки, не проверки) — это как раз почему закладок быть не может.
Аккуратности ради: моргать можно любым диодом, равно как и принимать свет. Просто какие‐то оптимизированы на излучение, какие‐то на регистрацию, а какие‐то предназначены для чего‐то ещё.
Нет, не могли бы. Проверить своё, значит проверить, что кристалл на выходе соответствует топологии, которую сделали свои инженеры на основе своего HDL кода. Проверить чужое при том, что детали топологии и HDL код неизвестны — значит взять кристалл, определить какие там элементы и с чем соединяются (нужны очень дорогие микроскопы с современными нормами), на основе этого отреверсить HDL код и в этом коде (который будет читаться не лучше результатов декомпиляции обычных программ) попытаться найти закладку. Учтите ещё и то, что даже если тот же Intel нам выдаст всё, что у него есть по своим процессорам, грамотно замаскированную закладку могут всё равно не найти.
Другими словами, для такой проверки нужно более дорогое оборудование и инженеры с весьма специфическими квалификациями.
Вообще‐то не совсем так: для того, чтобы у земли был радиус ей достаточно всего лишь иметь точную верхнюю грань всевозможных расстояний между её точками. Впрочем, я не удивлюсь, если кто‐то утверждает, что земля плоская и бесконечная.
И много у вас такой информации, которой вы готовы поделится, которую вы не забудете (особенно лет через 10) и которую нельзя подобрать по словарю, с учётом того, что вы не должны использовать один и тот же ответ на разных сервисах по тем же причинам, по которым вы не должны использовать один и тот же пароль?
Я всегда считал, что контрольный вопрос — это второй пароль. Если я не собираюсь забывать первый, то он не нужен, а если я не хочу, чтобы смог войти злоумышленник, то контрольный вопрос должен быть так же надёжен. Поэтому там обычно случайная строка символов, которую я нигде не сохранил.
Кстати, автор не прав и там можно отправить запрос в поддержку: «не могу войти в аккаунт» — «не помню пароль» — «у меня не получилось восстановить пароль самостоятельно» — «написать в службу поддержки», тогда откроется форма.
Уже есть ISO 8601, в нём неделя начинается с понедельника.