А где у вас там мнение? Я увидел одни только эмоции. С таким пренебрежением рассказываете на весь интернет про едва знакомого человека («снежинка» «с тараканами», «больше она у нас не работала», «полетела дальше на биржу труда»), что аж читать неприятно.
К слову, есть вполне себе легитимные причины хотеть конкретную клавиатуру — больные суставы, например.
Если новый работник за 10 минут решит правильно задачу над которой универовский профессор сидел 2 года (утрирую), то искать работу пойдёт профессор, а не новый работник.
Это гипотетическая ситуация или вы своими глазами такое видели? В моей реальности:
Никто не будет ждать два года, а подключат подмогу значительно быстрее.
Если задачу не могут решить два года и ничего не стряслось, значит, не очень важная задача.
Новопришедшие сотрудники крайне редко способны за десять минут решить то, над чем давно бьются старые.
Решение, придуманное посторонним человеком за десять минут, почти наверняка не учитывает всех требований, и, собственно, не является решением.
В конечном итоге все работают за деньги, которые платят за скорость и правильность. И не важно, хоть ты у инопланетян подсмотрел свое решение - это не важно.
Разным людями деньги платят за разное. Кому-то за скорость и правильность решения, кому-то за ответственность за результат, кому-то за красивые глаза. Если, в конечном счёте, неважно, как именно ты заработал деньги, в университетскую программу для разработчиков нужно срочно добавить курсы по современной моде, актёрскому мастерству и корпоративным интригам.
Решение состоит в том, чтобы [...] обсуждать [...] как chatgpt нам может помочь в создании лучшего решения.
Увы, но нет, это не будет работать. Какое такое «лучшее решение» найдёт при помощи ChatGPT студент, который не владеет базой по предмету и не в состоянии даже говорить с нейросетью на равных?
Кстати, вы себе вообще представляете такое занятие в академическом сеттинге? Вот рассказывет лектор, для примера, про признаки сходимости рядов или законы Кирхгофа — в каком именно месте рассказа ему нужно начать говорить про то, как правильно пользоваться языковыми моделями?
нужно студентам объяснять как правильно/наиболее эффективно его использовать
Нет никакой необходимости делать на этом акцент. Этому студенты и сами научатся.
Вот о чём бы вы рассказали студентам в семестровом курсе «Эффективное использование больших языковых моделей для решения задач {название близкой вашему сердцу дисциплины}»?
Рад слышать, что не потащили весь этот бред от французов. Хотя мне почему-то казалась, что я читал про эти дурные правила именно в контексте российской «Школы-21», буквально несколько лет назад.
либо я не понял требование
У них там есть такие пункты:
A structure’s name must start by s_.
An enum’s name must start by e_
Если им следовать, то, например, каждое упоминание типа структуры оказываются сразу с двумя префиксами — struct (требуется грамматикой C) и s_ (требуется кодстайлом E42).
В условиях отсутствует важная информация — сколько ожидается правил для фильтрации и есть ли в этих правилах какие-то структуры и закономерности, на которые можно опереться при оптимизации.
[...] преподаватели из моего института начали приставать ко мне с вопросами о "безопасной" передаче пароля
Не стоит так высокомерно отзываться о преподавателях, даже если они действительно бегают за вами и умоляют захешировать пароли (в чём я лично сомневаюсь). Иначе зачем вы у них учитесь?
Пример механизма защиты с солью:
В вашем протоколе (по крайней мере, в том виде, в котором вы его описали) есть фатальный недостаток. Если злоумышленник каким-либо способом получит базу данных с хешированными паролями, он сразу же, безо всякого брутфорса и радужных таблиц, сможет авторизоваться от имени любого пользователя системы.
Если я правильно понимаю, вы предлагаете следующую схему (иллюстрация вольным псевдокодом):
server:
# Генерируем «динамическую» соль.
dsalt = gen_random_salt()
session.dsalt = dsalt
send(dsalt)
client:
dsalt = recv()
# А тут уже соль «статическая», но разная для разных пользователей.
h = hash(kdf(password, salt, parameters), dsalt)
send(username, h)
server:
(username, h) = recv()
dsalt = session.dsalt
kdfSavedValue = db.getKdfValue(username)
hExpected = hash(kdfSavedValue, dsalt)
if h == hExpected:
allowAccess()
else:
denyAccess()
Здесь hash — некоторая стойкая хеш-функция с солью, kdf — функция формирования ключа с солью и параметрами (вы называете этот этап «хеширует свой пароль, как это делает сервер»).
Обратите внимание, что в этой схеме для вычисления hExpected не требуются ни соль, ни параметры KDF-функции, поскольку расчёт фактически перенесён с сервера на клиента, а проверяется уже готовый результат. А значит, если у злоумышленника есть слитая база с готовыми результатами, ему достаточно просто вычислить хеш и всё:
в некоторых случаях еще и домен назначения учитывается при выборе туннеля
А каким софтом можно такую красоту настроить так, чтобы было более-менее удобно жить? Известные мне способы требуют много интересных консольнх команд и несколько свободных вечеров.
Я как-то почитал кодстайл Ecole 42, и у меня сложилось мнение, что там цель не научить людей программировать, а заставить их страдать и подчиняться сумасбродным правилам. Французский иностранный легион какой-то.
У них там самый худший кодстайл, что видел в своей жизни:
жёсткий лимит на количество локальных переменных (целых 5 штук),
жёсткий лимит на количество параметров у функции (4 штуки),
жёсткий лимит на длину функции (20 строк),
жёсткий лимит на количество функций в файле (5 штук),
запрет на цикл for и switch,
запрет на пустые строки внутри функции,
запрет на объявление переменных не в начале функции,
запрет на объявление переменных с инициализацией,
выравнивание кода табами в середине строки,
избыточные (для языка C) префиксы для структур и энумов.
Всё обязательно к исполнению и энфорсится софтиной. Баги софтины считаются правилами. Судя по тому что я видел в группе студентов этой школе, куча времени тратится на придумывание способа вместиться в лимит по строками/переменным.
этот раздел я то ли прогулял, то ли произошло какое-то вытеснение
Не исключено, что в университете в курсе векторного и тензорного анализа до тензоров просто не дошли. У меня был такой курс, но именно тензорам досталось одно занятие в последнюю неделю перед сессией — всё остальное время в нас вколачивали векторные поля, дивергенции и роторы. И кажется, что это было правильно: досконально разбираться в тензорах нужно только на некоторых специальностях теоретической физики. В общем, может и не нужно лезть в тензоры лезть, если нет практической необходимости?
Мне в какой-то момент жизни захотелось поработать с уравнениями Максвелла в необычных координатах, и я вспомнил, что там было что-то про тензоры. Найти нужные формулы и понять, как их применить, мне тогда сильно помогла методичка:
— Р. А. Шарипов «Быстрое введение в тензорный анализ».
... чтобы крупному капиталу поменьше тратиться на оплату труда людей. Ну, нас с вами, то есть.
оставить зажравшихся рисовак без денег после десятилетий диктования ими завышенных цен на свои услуги
А какие у «зажравшихся рисовак» расценки, кстати? Почему вы думаете, что они зажрались, а мы, разработчки, нет? Мне почему-то казалось, что профессия художника в последние десятилетия настолько обесценилась, а конкуренция — настолько выросла, что немногие могут заработать этим на хорошую жизнь. Регулярно встречаю в интернете рассказы про страшную потогонку в геймдеве и студиях анимации.
В общем случае да, хорошие пароли на все учётки. Когда писал, в голове был кейс «виртуалка за 5 баксов специально под прокси, настроил и забыл», где нет смысла заводить простых пользователей.
На последок хотелось бы сказать самые простые и примитивные вещи [...]
Не думаю, что люди, которые копипастят гайды, способны просто взять и последовать вашим рекомендациям. К тому же они не бесспорные. Вместо всего этого я бы рекомендовал неопытным админам, которым просто нужна виртуалка для VPN:
не трогать дефолтные настройки sshd и фаервола, они совершенно нормальны из коробки,
если по какой-то причине ваш хостер настроил авторизацию по паролям, поставить на рутовую учётку хороший пароль из 30+ случайных символов.
Потому что не хотелось слишком уж сильно душнить, да и тогда бы пришлось думать, а по сверхновым быстро удобная формула попалась на глаза. И постановка задачи (кубический километр льда) как будто бы прям отсылка к IceCube.
над проблемой сохранности сверхбольших объемов данных
Недавно пытался разгрести свои старые файлы — не сверхбольшие объёмы, конечно, просто каталоги «Разобрать»/«Старое»/«Не знаю куда» где-то за десять лет — и много раз ловил себя на мысли, что из всего этого барахла через условные сто лет представлять хотя бы крошечный интерес ну хотя бы для кого-то в мире будет хорошо если пара мегабайт. Возможно, человечеству, как и мне, стоит хранить поменьше барахла и поменьше о нём переживать.
становится измеримой величина ошибок, которые могут вызвать частицы, приходящие из космоса
Да тут, увы, даже ECC-память в масс-маркет никак не завезут. Давно присматриваюсь, но прям дорого как-то получается. Так и приходится жить с осознанием риска.
Кстати, а у вас случайно нет реальных цифр, сколько примерно в год на среднем сервере набегает ошибок ECC? Контроллер памяти ведь ведёт такую статистику?
Думаю, у этой задачи нет правильного ответа, есть некая модель в голове автора, которую предлагается угадать. Если это серьёзная задача на реалистичную оценку числа событий взаимодействия излучения с веществом, не очень-то интересно его считать на серьёзных щах. Если это «задача с подвохом», не очень интересно его искать.
Если пытаться придерживаться реализма, то могу дать такую оценку на пальцах:
По данным Википедии, в среднем в нашей галактике случается 2-12 сверхновых в год.
Диаметр галактики 30 кпс, то есть до средней сверхновой получается примерно 20 кпс расстояния.
Тогда по формуле из Википедии кубический километра льда наловит за 7,5 млн лет примерно 10^16 достаточно злых нейтрино.
Влияние солнечных нейтрино за тот же срок будет пренебрежимо мало, а от других частиц «сверхразумная раса», надеюсь, уж как-нибудь защитит свой вычислительный куб.
Так что пусть будет 10^16 «ошибок». И дальше-то с этой цифрой что делать?
А также о том, что целевая аудитория нашего курса - разработчики, которым требуется выучить C++. То есть люди с ненулевым багажом знаний и опыта.
Пока дочитал статью до конца, забыл начало.
Даже безотносительно опыта и знаний студентов, я всё же считаю, что C++ относится к тем технологиям, которые нельзя нормально понять и эффективно использовать без изучения внутреннего устройства. Си прям неплохо подходится для этого: вверх по абстракциям идти проще, чем вниз.
Меня смущает, что вы говорите про разработчика на C++, но в 3-х пунктах из 4-х C++ вообще отсутствует
Так мой тезис же был про то, что C++-разработчику нужно знать и то, что не си++.
Интересно было бы послушать про ваш бэкграунд
Я бы назвал свой бэкграунд «R&D без привязки к языку», в последнее время больше с FPGA работаю. Из недавнего на си++ — математика (линейная алгебра, многопараметрическая оптимизация), микроконтроллеры (да, на C++), тестбенчи для FPGA-кода (если добавить к Verilator немного обвязки на корутинах, получает весьма неплохо по производительности и выразительности кода). Периодически пишу что-нибудь с кнопками при помощи Qt.
... ситуации, в которых ассемблерным вставкам нет альтернатив.
Например, когда вам нужно написать свой (или адаптировать вендорный) стартовый файл для нового микроконтроллера. Увести МК в прерывание. На лету переключить потоку стек. Вставить memory fence, CAS, векторную инструкцию. Часть этих кейсов закрывается интринсиками, но например, интринсиков под нужные инструкции RISC-V в компиляторе может просто ещё не быть.
Куда чаще на ассемблер приходится смотреть, чтобы хотя бы поверхностно понять, заинлайнились ли вызовы, догадался ли компилятор развернуть или векторизовать цикл, и тому подобное.
Вот только C++ отвратителен как первый язык. Погружаться в плюсы, не имея базы приемлемой низкоуровневой базы, как по мне, неудачная идея. Ну не может компетентный C++-разработчик не представлять, во что его структуры выложатся в памяти, как компилятор реализует виртуальные функции, как раскручивается стек при исключениях, и т.д. И тут можно опираться только на ассемблер (в совсем низкоуровневых вещах) да на си без плюсов (в менее низкоуровневых).
Это будет плохой код.
На самом деле нет. Плохой код будет только в том случае, если после курса по C студент решит, что и С++ он уже знает и незачем ещё чему-то учиться. Таких людей обучать можно любым языкам в любой последовательности, с тем же результатом.
Но согласитесь, он далек от оптимума по соотношению затраченных сил/времени к результату.
(В ответ на сообщение уровнем выше)
Это зависит от того, каким вы видите результат. В моём представлении требования к компетентному C++-разработчику включают в себя:
знание отличий C и C++;
умение при необходимости программировать на C в согласии с местными идиомами (привет goto exit;);
умение при необходимости сориентироваться в ассемблерном листинге;
способность при необходимости разобраться, как написать ассемблерную вставку или линкер-скрипт, даже если это нужно всего раз в год.
Посмотрел на примеры кода в статье. Я правильно понимаю, что товарищи из 1С умудрились спроектировать язык, в котором одновременно:
обязательные отступы и ньюлайны,
обязательный end для каждой конструкции (причём в форме точки с запятой)?
Где-нибудь можно взглянуть на формальную грамматику этого ЯП?
А где у вас там мнение? Я увидел одни только эмоции. С таким пренебрежением рассказываете на весь интернет про едва знакомого человека («снежинка» «с тараканами», «больше она у нас не работала», «полетела дальше на биржу труда»), что аж читать неприятно.
К слову, есть вполне себе легитимные причины хотеть конкретную клавиатуру — больные суставы, например.
Это гипотетическая ситуация или вы своими глазами такое видели? В моей реальности:
Никто не будет ждать два года, а подключат подмогу значительно быстрее.
Если задачу не могут решить два года и ничего не стряслось, значит, не очень важная задача.
Новопришедшие сотрудники крайне редко способны за десять минут решить то, над чем давно бьются старые.
Решение, придуманное посторонним человеком за десять минут, почти наверняка не учитывает всех требований, и, собственно, не является решением.
Разным людями деньги платят за разное. Кому-то за скорость и правильность решения, кому-то за ответственность за результат, кому-то за красивые глаза. Если, в конечном счёте, неважно, как именно ты заработал деньги, в университетскую программу для разработчиков нужно срочно добавить курсы по современной моде, актёрскому мастерству и корпоративным интригам.
Увы, но нет, это не будет работать. Какое такое «лучшее решение» найдёт при помощи ChatGPT студент, который не владеет базой по предмету и не в состоянии даже говорить с нейросетью на равных?
Кстати, вы себе вообще представляете такое занятие в академическом сеттинге? Вот рассказывет лектор, для примера, про признаки сходимости рядов или законы Кирхгофа — в каком именно месте рассказа ему нужно начать говорить про то, как правильно пользоваться языковыми моделями?
Нет никакой необходимости делать на этом акцент. Этому студенты и сами научатся.
Вот о чём бы вы рассказали студентам в семестровом курсе «Эффективное использование больших языковых моделей для решения задач {название близкой вашему сердцу дисциплины}»?
Рад слышать, что не потащили весь этот бред от французов. Хотя мне почему-то казалась, что я читал про эти дурные правила именно в контексте российской «Школы-21», буквально несколько лет назад.
У них там есть такие пункты:
A structure’s name must start by s_.
An enum’s name must start by e_
Если им следовать, то, например, каждое упоминание типа структуры оказываются сразу с двумя префиксами —
struct(требуется грамматикой C) иs_(требуется кодстайлом E42).В условиях отсутствует важная информация — сколько ожидается правил для фильтрации и есть ли в этих правилах какие-то структуры и закономерности, на которые можно опереться при оптимизации.
Не стоит так высокомерно отзываться о преподавателях, даже если они действительно бегают за вами и умоляют захешировать пароли (в чём я лично сомневаюсь). Иначе зачем вы у них учитесь?
В вашем протоколе (по крайней мере, в том виде, в котором вы его описали) есть фатальный недостаток. Если злоумышленник каким-либо способом получит базу данных с хешированными паролями, он сразу же, безо всякого брутфорса и радужных таблиц, сможет авторизоваться от имени любого пользователя системы.
Если я правильно понимаю, вы предлагаете следующую схему (иллюстрация вольным псевдокодом):
Здесь
hash— некоторая стойкая хеш-функция с солью,kdf— функция формирования ключа с солью и параметрами (вы называете этот этап «хеширует свой пароль, как это делает сервер»).Обратите внимание, что в этой схеме для вычисления
hExpectedне требуются ни соль, ни параметры KDF-функции, поскольку расчёт фактически перенесён с сервера на клиента, а проверяется уже готовый результат. А значит, если у злоумышленника есть слитая база с готовыми результатами, ему достаточно просто вычислить хеш и всё:Что некоторые (многие?) примеры действительно слегка притянуты за уши и тянут на одну-две совы максимум. Не «отбитая дичь», а ожидаемое поведение.
А каким софтом можно такую красоту настроить так, чтобы было более-менее удобно жить? Известные мне способы требуют много интересных консольнх команд и несколько свободных вечеров.
Я как-то почитал кодстайл Ecole 42, и у меня сложилось мнение, что там цель не научить людей программировать, а заставить их страдать и подчиняться сумасбродным правилам. Французский иностранный легион какой-то.
У них там самый худший кодстайл, что видел в своей жизни:
жёсткий лимит на количество локальных переменных (целых 5 штук),
жёсткий лимит на количество параметров у функции (4 штуки),
жёсткий лимит на длину функции (20 строк),
жёсткий лимит на количество функций в файле (5 штук),
запрет на цикл for и switch,
запрет на пустые строки внутри функции,
запрет на объявление переменных не в начале функции,
запрет на объявление переменных с инициализацией,
выравнивание кода табами в середине строки,
избыточные (для языка C) префиксы для структур и энумов.
Всё обязательно к исполнению и энфорсится софтиной. Баги софтины считаются правилами. Судя по тому что я видел в группе студентов этой школе, куча времени тратится на придумывание способа вместиться в лимит по строками/переменным.
Не исключено, что в университете в курсе векторного и тензорного анализа до тензоров просто не дошли. У меня был такой курс, но именно тензорам досталось одно занятие в последнюю неделю перед сессией — всё остальное время в нас вколачивали векторные поля, дивергенции и роторы. И кажется, что это было правильно: досконально разбираться в тензорах нужно только на некоторых специальностях теоретической физики. В общем, может и не нужно лезть в тензоры лезть, если нет практической необходимости?
Мне в какой-то момент жизни захотелось поработать с уравнениями Максвелла в необычных координатах, и я вспомнил, что там было что-то про тензоры. Найти нужные формулы и понять, как их применить, мне тогда сильно помогла методичка:
— Р. А. Шарипов «Быстрое введение в тензорный анализ».
Бесплатная, всего 50 страниц в PDF.
... чтобы крупному капиталу поменьше тратиться на оплату труда людей. Ну, нас с вами, то есть.
А какие у «зажравшихся рисовак» расценки, кстати? Почему вы думаете, что они зажрались, а мы, разработчки, нет? Мне почему-то казалось, что профессия художника в последние десятилетия настолько обесценилась, а конкуренция — настолько выросла, что немногие могут заработать этим на хорошую жизнь. Регулярно встречаю в интернете рассказы про страшную потогонку в геймдеве и студиях анимации.
В общем случае да, хорошие пароли на все учётки. Когда писал, в голове был кейс «виртуалка за 5 баксов специально под прокси, настроил и забыл», где нет смысла заводить простых пользователей.
Не думаю, что люди, которые копипастят гайды, способны просто взять и последовать вашим рекомендациям. К тому же они не бесспорные. Вместо всего этого я бы рекомендовал неопытным админам, которым просто нужна виртуалка для VPN:
не трогать дефолтные настройки sshd и фаервола, они совершенно нормальны из коробки,
если по какой-то причине ваш хостер настроил авторизацию по паролям, поставить на рутовую учётку хороший пароль из 30+ случайных символов.
Слово «ёкодзуна» пишется, всё-таки, через «ё». Или это умышленное искажение?
Потому что не хотелось слишком уж сильно душнить, да и тогда бы пришлось думать, а по сверхновым быстро удобная формула попалась на глаза. И постановка задачи (кубический километр льда) как будто бы прям отсылка к IceCube.
Недавно пытался разгрести свои старые файлы — не сверхбольшие объёмы, конечно, просто каталоги «Разобрать»/«Старое»/«Не знаю куда» где-то за десять лет — и много раз ловил себя на мысли, что из всего этого барахла через условные сто лет представлять хотя бы крошечный интерес ну хотя бы для кого-то в мире будет хорошо если пара мегабайт. Возможно, человечеству, как и мне, стоит хранить поменьше барахла и поменьше о нём переживать.
Да тут, увы, даже ECC-память в масс-маркет никак не завезут. Давно присматриваюсь, но прям дорого как-то получается. Так и приходится жить с осознанием риска.
Кстати, а у вас случайно нет реальных цифр, сколько примерно в год на среднем сервере набегает ошибок ECC? Контроллер памяти ведь ведёт такую статистику?
Думаю, у этой задачи нет правильного ответа, есть некая модель в голове автора, которую предлагается угадать. Если это серьёзная задача на реалистичную оценку числа событий взаимодействия излучения с веществом, не очень-то интересно его считать на серьёзных щах. Если это «задача с подвохом», не очень интересно его искать.
Если пытаться придерживаться реализма, то могу дать такую оценку на пальцах:
По данным Википедии, в среднем в нашей галактике случается 2-12 сверхновых в год.
Диаметр галактики 30 кпс, то есть до средней сверхновой получается примерно 20 кпс расстояния.
Тогда по формуле из Википедии кубический километра льда наловит за 7,5 млн лет примерно 10^16 достаточно злых нейтрино.
Влияние солнечных нейтрино за тот же срок будет пренебрежимо мало, а от других частиц «сверхразумная раса», надеюсь, уж как-нибудь защитит свой вычислительный куб.
Так что пусть будет 10^16 «ошибок». И дальше-то с этой цифрой что делать?
Пока дочитал статью до конца, забыл начало.
Даже безотносительно опыта и знаний студентов, я всё же считаю, что C++ относится к тем технологиям, которые нельзя нормально понять и эффективно использовать без изучения внутреннего устройства. Си прям неплохо подходится для этого: вверх по абстракциям идти проще, чем вниз.
Так мой тезис же был про то, что C++-разработчику нужно знать и то, что не си++.
Я бы назвал свой бэкграунд «R&D без привязки к языку», в последнее время больше с FPGA работаю. Из недавнего на си++ — математика (линейная алгебра, многопараметрическая оптимизация), микроконтроллеры (да, на C++), тестбенчи для FPGA-кода (если добавить к Verilator немного обвязки на корутинах, получает весьма неплохо по производительности и выразительности кода). Периодически пишу что-нибудь с кнопками при помощи Qt.
Например, когда вам нужно написать свой (или адаптировать вендорный) стартовый файл для нового микроконтроллера. Увести МК в прерывание. На лету переключить потоку стек. Вставить memory fence, CAS, векторную инструкцию. Часть этих кейсов закрывается интринсиками, но например, интринсиков под нужные инструкции RISC-V в компиляторе может просто ещё не быть.
Куда чаще на ассемблер приходится смотреть, чтобы хотя бы поверхностно понять, заинлайнились ли вызовы, догадался ли компилятор развернуть или векторизовать цикл, и тому подобное.
Вот только C++ отвратителен как первый язык. Погружаться в плюсы, не имея базы приемлемой низкоуровневой базы, как по мне, неудачная идея. Ну не может компетентный C++-разработчик не представлять, во что его структуры выложатся в памяти, как компилятор реализует виртуальные функции, как раскручивается стек при исключениях, и т.д. И тут можно опираться только на ассемблер (в совсем низкоуровневых вещах) да на си без плюсов (в менее низкоуровневых).
На самом деле нет. Плохой код будет только в том случае, если после курса по C студент решит, что и С++ он уже знает и незачем ещё чему-то учиться. Таких людей обучать можно любым языкам в любой последовательности, с тем же результатом.
(В ответ на сообщение уровнем выше)
Это зависит от того, каким вы видите результат. В моём представлении требования к компетентному C++-разработчику включают в себя:
знание отличий C и C++;
умение при необходимости программировать на C в согласии с местными идиомами (привет
goto exit;);умение при необходимости сориентироваться в ассемблерном листинге;
способность при необходимости разобраться, как написать ассемблерную вставку или линкер-скрипт, даже если это нужно всего раз в год.