Архитектуру они сделали точно не с нуля, с этого меня и бомбануло.
Так я и говорю, что сейчас сделать совсем с нуля и невозможно, и не нужно. Всё равно 99% решений будут общими и универсальными.
А вот то, что они сделали очередную оценку оптимизации и что-то перестроили не только по сравнению со старым MIPS (который действительно был в заметной мере основан на идеях ещё 1980-х), но и по сравнению с уже известным RISC-V — это интересно как минимум оценкой того, о чём и как они думали.
Изменение же бинарной кодировки команд, это как у русского текста сменить кодировку и сказать что это не копия, а что-то новое.
Я вот только начал смотреть и уже вижу, например:
Нет MIPSовского различия add/addu, sub/subu, etc., где первый в паре никем не использовался.
Нет MIPS/64 проблемы "64-битный регистр это два 32-битных", которая очень портила кровь компиляторам.
addu16i.d, lu12i.w, lu32i.d, lu52i.d, и ещё пачка команд — пытаются решить проблему констант-литералов в самих командах (MIPS — нормально не решалась, RISC-V — решается для 32 бит просто, а для 64 — рекомендуется читать из памяти; ARM/64 — решается штатно). Здесь как раз вопрос, почему они решили, что подхода RISC-V не хватит. Одного регистра жалко?
Есть nor, но нет nand, nxor — явная заточка под какие-то целевые применения. И снова аналога нет. orn — особенно (я не понимаю, кому она такая нужна, в отличие от andn).
mulh: подход осовремененный (а-ля RISC-V, но не MIPS).
Можно продолжать, но мне лично уже достаточно для вывода: все эти отличия существенны для них, и какая-то часть точно на пользу; и ради них перекроение кодировки команд — это не только ради несовместимости.
Инструкции прыжка без флагов, потому что отсутствие флагов унаследовано от MIPS. r0 равный нулю — тоже как в MIPS.
Вас послушать, так надо было строить ISA на троичной системе счисления, потому что иначе это ребрендинг всех подряд, начиная с x86 ;\
Пустой регистр — это универсальная фишка, которую, после того, как её вообще придумали, хотят все — потому что действительно потрясающе удобно. ARM/64 и Alpha тоже имеют такое, ну а то, что у них этот регистр не номер 0, а (о ужас) 31 — сути не меняет. 0 понятнее человеку. Даже на древнейшей S/360 регистр 0 читался как ноль для адресных команд (не для всех, да — чуть недоработали).
Отсутствие флагов — универсальная фишка RISC, особенно тех, кто хочет поддерживать минималистичные реализации, где не хочется следить за ещё пачкой однобитовых регистров. Тем более, что переложение логики, которая пишется на ЯВУ и транслируется в промежуточный код LLVM, GCC генератором и аналогами, на стиль с флагами в PS — требует отдельного уровня трансляции, а стиль RISC тут ложится существенно прямее. Когда >99.9% исполняемого кода генерируется компилятором — это важно.
А ещё безфлаговый стиль лучше совместим с векторным — потому что в векторах флагов на всех не напасёшься, а главное — фиг их одновременно проверишь. И снова — легче это компилировать.
Стиль JIRL/JALR/etc. был стандартным до массовой CISC-изации 1970-х — посмотрите в ту же S/360 (BAL, BRASL...) Для RISC он лучше — из разложения на микрооперации типа "положить значение PC в стек, сдвинуть указатель стека, обновить PC" уходит как минимум один компонент.
и там, не поверите, используются векторные инструкции явно скопированные из MMX от x86.
Все векторные комплекты команд друг на друга похожи как капли воды, потому что решают одни и те же задачи.
и по сути просто ребрендинг провального продукта
MIPS успешно работал, будучи основным для широкого спектра встроенных применений, сетевых устройств и т.п. — в течение примерно 30 лет. ARM его начал вытеснять только в 2000-х, успешно в 2010-х, и то продолжают идти новые разработки на MIPS. Чтобы назвать это "провальным", надо не дружить с фактами.
На будущее посоветую детальнее ознакомиться, как минимум, с историей IT.
Спрашивается, где найти желающих рисковать в таком чувствительном деле как управление сервером?
Неее, не проходит такая логика. Потому что тогда была бы единственная система управления стартом/стопом (да, systemd занимает сейчас бо́льшую часть, но есть много возможностей ставить без него), единственный пакетный менеджер (а сейчас rpm+yum, rpm+dnf, deb+apt, pacman, и ещё десяток)...
Или что, компиляция не ответственное дело? По-моему, более ответственное даже. Имеем GCC, Clang+LLVM, ICC, Open64 в двух клонах, и ещё парочку простейших, пригодных для контроля корректности компиляции.
Или управление сетью — тоже критично для "управления сервером": даже не вспоминая облачные средства — на NetworkManager свет клином не сошёлся.
миграция на IPv6. Расширение адресного пространства усложнит работу злоумышленников, которым станет в разы труднее его сканировать.
Не поможет. Те системы, что сейчас с индивидуальными IP под IP4, будут с такими и с IP6. Там, где сейчас выдают условный 1.2.3.4, будут выдавать 1:2:3:400/56, в котором всё равно будут использовать ::1, ::2 и так далее, потому что иначе люди зашьются с этим работать. А там, где будет работать автоназначение, например, на OUI, там на IP4 такие же пользователи за NAT.
Зато, наоборот, будет прямой доступ к системам пользователей. А о нормальном распределении прав доступа, например, на основе SLAAC никто и не пытается думать.
OpenSSH вообще очень странная штука.
У меня были ситуации с ним, например, не принимает конкретный ключ в authorized_keys. Или автоматически первым пунктом зовёт auth=none, но так, что pam_unix видит проверку с пустым паролем для акаунта с реальным паролем и тормозит процесс на пару секунд, а sshd решает, что раз была задержка, надо её усилить, и добавляет ещё две секунды. Или из проб приватных ключей берёт только первые 4, а остальные пропускает (ну вот надо было в конфиге по умолчанию много ключей вписать). Код написан местами вредительски.
А то, что все ключи надо собирать в один файл и свойства к ним писать в потенциально опасном формате? (там где no-agent-forwarding, forced_command и всё такое)
Я бы даже сказал, что основная проблема с ним это безальтернативность. Есть, фактически, одна реализация на всех. Dropbear есть, но ограничен по свойствам. LSH по сути умер. Реализация от ssh.fi зохавана корпорастами.
Почему, в отличие от 100500 других средств, нет альтернативных реализаций, например, от GNU или Apache?
Давайте поисковик будут выдавать вам информацию в режиме "для блондинок". Вам понравится работать с таким?
"Для блондинок" — это перебор и передёрг. А вот для человека, который не разбирается в теме, а только начинает про неё спрашивать — да, это нормальный вариант по умолчанию. Википедия, например, стремится к такому — обратите внимание на первые предложения каждой статьи о чём-то нетривиальном.
Тут, да, нужен контекст. В ChatGPT и Bing он есть хотя бы на несколько последних вопросов. Дальше, думаю, его будут увеличивать.
А я обязан это указывать?
Пока "оно" не знает что пивовар — да, обязаны. Хотя бы первый раз.
Версия 3.5 была интересна разве что смешными ответами
В своём персональном опыте я говорю про 3.5. 4-ю не хочу сильно обсуждать потому, что доступ к ней покамест платный.
Уже с 3.5 есть много полезных ответов, не только с"смешные".
когда я учил студентов и аспирантов в университете — так они еще и не такое порой выдавали
То от лени. А эта штука (в любой версии) таки напрягается.
Сурьёзно? То есть пивовары -люди ё*нутые на всю голову?
Про "на всю голову" я не говорил. А вот уровень "рассеянного профессора" безусловно входит в множество определённых мной вариантов. Если будет рассказывать первому встречному, и не в режиме баек за стаканом в поезде, а в ответ на конкретный вопрос.
Откуда боту знать мою квалификацию? А если я — пивовар?
Вы видите в скриншоте "ответь как пивовар пивовару"?
Вы ведь понимаете, что даже "банальности" и есть правильным ответом?
А вы понимаете, что в первую очередь спрашивающему требуется полезность ответа и только потом (в большинстве случаев) правильность?
Причём, в некоторых случаях частично неправильный ответ бывает полезнее. Половина тех, кто едет в троллейбусе и отвечает по мобиле "ты где?" говорит свою локацию на остановку-две вперёд реального, потому что это стимулирует слушающего, например, быстрее оторваться от телевизора и разогреть ужин.
Напрямую на ответы поисковика это сложно спроецировать, но я говорю про общие принципы.
Банальности, которые эти сети говорят, полезны для самых первых ответов, когда спрашивающий вообще ничего не знает, и для понимания, в каком контексте идёт ответ. Но уже при минимальном знании вопрошающем, о чём же он спрашивает, этот поток банальностей становится просто шумом.
Я это регулярно прохожу во время квестов типа "найди, как же сформулировать вопрос, чтобы оно выбросило ненужное и разделило то, что надо разделять".
ChatGPT пока не дорос до уровня WishMaster)
Я не знаю, о каком WishMaster речь, но факт тот, что на часть вопросов, где нет таких проблем, оно очень хорошо отвечает (вплоть до образцов кода/конфига с расшифровкой), а на часть — ужасно, и я вижу это именно на ситуациях, когда контексты описаны одинаковыми словами.
Когда ИИ с джуном под руководством Тимлида сравнивают. И Тимлид — таки вы же)))
А вы что, готовое пиво солите, сладкое вишневое например?
Ну есть знакомые которые постоянно солят пиво. Сладкое они вроде не пьют, но я бы понял вопрос именно так. Причём сказал бы "да, бери то, что "меньше натрия"" — потому что при таком потреблении надо дать хотя бы такую помощь организму держать баланс солей.
Например, можно код условного "-128" объявить как целочисленный NaN
Процессорных не видел. Программно — в kdb+ именно так и сделано.
В однобайтных, 0x80 = NaN, 0x7f = +Inf, 0x81 = -Inf.
Правда, там криво — если расширить до 2 байтов и выше, 0x7f переходит в 127. Намеренно недоработано для скорости обработки данных.
Есть ещё разные статьи с предложениями подобной арифметики как защитного подхода.
Нет, потому что натягивания не было. Вот спешка при написании ответа и следы больше разговорного стиля с повтором тезисов — было, за это вынужден просить прощения.
Обоснование же сути ответа — я по своему опыту общения с ChatGPT получил примерно те же выводы, что и автор. В этот раз конкретно на примере стоп-кранов это не повторилось, но в других случаях я регулярно получаю ответы системы "70% банальностей, 25% полезного и верного и 5% полного бреда", потому что оно скомпилировало именно так, не заметив какой-то тонкости.
А самое неприятное — это когда смешиваются более одного контекста, которые разделяются не одним словом, а длинными (от 3 слов и более) словосочетаниями, тогда оно вообще не может понять разницу и в выдаче даёт дикую смесь из всего найденного. Не буду вдаваться в детали, потому что подозрительно близко к NDA, но пример был про кастомный аналог make, который часть правил сборки отрабатывает сразу, а часть — откладывает на следующие стадии, так вот я с ~20 попыток не сумел найти, как ему объяснить, в какой из фаз сборки я пытаюсь задать свой порядок выполнения правил.
Человек бы понял максимум с 3-го повторения (ладно, с 5-го, если с бодуна).
Так я и говорю, что сейчас сделать совсем с нуля и невозможно, и не нужно. Всё равно 99% решений будут общими и универсальными.
А вот то, что они сделали очередную оценку оптимизации и что-то перестроили не только по сравнению со старым MIPS (который действительно был в заметной мере основан на идеях ещё 1980-х), но и по сравнению с уже известным RISC-V — это интересно как минимум оценкой того, о чём и как они думали.
Я вот только начал смотреть и уже вижу, например:
Нет MIPSовского различия add/addu, sub/subu, etc., где первый в паре никем не использовался.
Нет MIPS/64 проблемы "64-битный регистр это два 32-битных", которая очень портила кровь компиляторам.
addu16i.d, lu12i.w, lu32i.d, lu52i.d, и ещё пачка команд — пытаются решить проблему констант-литералов в самих командах (MIPS — нормально не решалась, RISC-V — решается для 32 бит просто, а для 64 — рекомендуется читать из памяти; ARM/64 — решается штатно). Здесь как раз вопрос, почему они решили, что подхода RISC-V не хватит. Одного регистра жалко?
Есть nor, но нет nand, nxor — явная заточка под какие-то целевые применения. И снова аналога нет. orn — особенно (я не понимаю, кому она такая нужна, в отличие от andn).
mulh: подход осовремененный (а-ля RISC-V, но не MIPS).
Можно продолжать, но мне лично уже достаточно для вывода: все эти отличия существенны для них, и какая-то часть точно на пользу; и ради них перекроение кодировки команд — это не только ради несовместимости.
Для этого надо чтобы его можно было читать, но запись в него вызывала немедленное исключение :))
(на IA64, как ни странно, регистр 0 именно такой)
Вас послушать, так надо было строить ISA на троичной системе счисления, потому что иначе это ребрендинг всех подряд, начиная с x86 ;\
Пустой регистр — это универсальная фишка, которую, после того, как её вообще придумали, хотят все — потому что действительно потрясающе удобно. ARM/64 и Alpha тоже имеют такое, ну а то, что у них этот регистр не номер 0, а (о ужас) 31 — сути не меняет. 0 понятнее человеку. Даже на древнейшей S/360 регистр 0 читался как ноль для адресных команд (не для всех, да — чуть недоработали).
Отсутствие флагов — универсальная фишка RISC, особенно тех, кто хочет поддерживать минималистичные реализации, где не хочется следить за ещё пачкой однобитовых регистров. Тем более, что переложение логики, которая пишется на ЯВУ и транслируется в промежуточный код LLVM, GCC генератором и аналогами, на стиль с флагами в PS — требует отдельного уровня трансляции, а стиль RISC тут ложится существенно прямее. Когда >99.9% исполняемого кода генерируется компилятором — это важно.
А ещё безфлаговый стиль лучше совместим с векторным — потому что в векторах флагов на всех не напасёшься, а главное — фиг их одновременно проверишь. И снова — легче это компилировать.
Стиль JIRL/JALR/etc. был стандартным до массовой CISC-изации 1970-х — посмотрите в ту же S/360 (BAL, BRASL...) Для RISC он лучше — из разложения на микрооперации типа "положить значение PC в стек, сдвинуть указатель стека, обновить PC" уходит как минимум один компонент.
Все векторные комплекты команд друг на друга похожи как капли воды, потому что решают одни и те же задачи.
MIPS успешно работал, будучи основным для широкого спектра встроенных применений, сетевых устройств и т.п. — в течение примерно 30 лет. ARM его начал вытеснять только в 2000-х, успешно в 2010-х, и то продолжают идти новые разработки на MIPS. Чтобы назвать это "провальным", надо не дружить с фактами.
На будущее посоветую детальнее ознакомиться, как минимум, с историей IT.
Неее, не проходит такая логика. Потому что тогда была бы единственная система управления стартом/стопом (да, systemd занимает сейчас бо́льшую часть, но есть много возможностей ставить без него), единственный пакетный менеджер (а сейчас rpm+yum, rpm+dnf, deb+apt, pacman, и ещё десяток)...
Или что, компиляция не ответственное дело? По-моему, более ответственное даже. Имеем GCC, Clang+LLVM, ICC, Open64 в двух клонах, и ещё парочку простейших, пригодных для контроля корректности компиляции.
Или управление сетью — тоже критично для "управления сервером": даже не вспоминая облачные средства — на NetworkManager свет клином не сошёлся.
Нет, тут что-то другое.
Не поможет. Те системы, что сейчас с индивидуальными IP под IP4, будут с такими и с IP6. Там, где сейчас выдают условный 1.2.3.4, будут выдавать 1:2:3:400/56, в котором всё равно будут использовать ::1, ::2 и так далее, потому что иначе люди зашьются с этим работать. А там, где будет работать автоназначение, например, на OUI, там на IP4 такие же пользователи за NAT.
Зато, наоборот, будет прямой доступ к системам пользователей. А о нормальном распределении прав доступа, например, на основе SLAAC никто и не пытается думать.
OpenSSH вообще очень странная штука.
У меня были ситуации с ним, например, не принимает конкретный ключ в authorized_keys. Или автоматически первым пунктом зовёт auth=none, но так, что pam_unix видит проверку с пустым паролем для акаунта с реальным паролем и тормозит процесс на пару секунд, а sshd решает, что раз была задержка, надо её усилить, и добавляет ещё две секунды. Или из проб приватных ключей берёт только первые 4, а остальные пропускает (ну вот надо было в конфиге по умолчанию много ключей вписать). Код написан местами вредительски.
А то, что все ключи надо собирать в один файл и свойства к ним писать в потенциально опасном формате? (там где no-agent-forwarding, forced_command и всё такое)
Я бы даже сказал, что основная проблема с ним это безальтернативность. Есть, фактически, одна реализация на всех. Dropbear есть, но ограничен по свойствам. LSH по сути умер. Реализация от ssh.fi зохавана корпорастами.
Почему, в отличие от 100500 других средств, нет альтернативных реализаций, например, от GNU или Apache?
Это и так очевидно. Вопрос, кто, как и зачем эту сеть тренировал...
То, что даёт Bing, это ну очень специфически доработанная GPT-4, по ней судить об оригинальной невозможно.
[mode=неполиткорректно] Вы не поделитесь фамилией и цветом волос этой нейросети? [/mode]
"Для блондинок" — это перебор и передёрг. А вот для человека, который не разбирается в теме, а только начинает про неё спрашивать — да, это нормальный вариант по умолчанию. Википедия, например, стремится к такому — обратите внимание на первые предложения каждой статьи о чём-то нетривиальном.
Тут, да, нужен контекст. В ChatGPT и Bing он есть хотя бы на несколько последних вопросов. Дальше, думаю, его будут увеличивать.
Пока "оно" не знает что пивовар — да, обязаны. Хотя бы первый раз.
Нет.
Ссылки гугла надо ещё разобрать.
А вот подсказку, по каким словам гуглить дальше, ChatGPT выдаёт очень неплохо.
Коллега использует его для коррекции своего несовершенного английского, перед отправкой заказчикам.
В своём персональном опыте я говорю про 3.5. 4-ю не хочу сильно обсуждать потому, что доступ к ней покамест платный.
Уже с 3.5 есть много полезных ответов, не только с"смешные".
То от лени. А эта штука (в любой версии) таки напрягается.
Про "на всю голову" я не говорил. А вот уровень "рассеянного профессора" безусловно входит в множество определённых мной вариантов. Если будет рассказывать первому встречному, и не в режиме баек за стаканом в поезде, а в ответ на конкретный вопрос.
Вы видите в скриншоте "ответь как пивовар пивовару"?
https://code.kx.com/q/basics/datatypes/
См. колонки null, inf. Хотя для постороннего, да, эта дока совсем зашифрованная.
А вы понимаете, что в первую очередь спрашивающему требуется полезность ответа и только потом (в большинстве случаев) правильность?
Причём, в некоторых случаях частично неправильный ответ бывает полезнее. Половина тех, кто едет в троллейбусе и отвечает по мобиле "ты где?" говорит свою локацию на остановку-две вперёд реального, потому что это стимулирует слушающего, например, быстрее оторваться от телевизора и разогреть ужин.
Напрямую на ответы поисковика это сложно спроецировать, но я говорю про общие принципы.
Банальности, которые эти сети говорят, полезны для самых первых ответов, когда спрашивающий вообще ничего не знает, и для понимания, в каком контексте идёт ответ. Но уже при минимальном знании вопрошающем, о чём же он спрашивает, этот поток банальностей становится просто шумом.
Я это регулярно прохожу во время квестов типа "найди, как же сформулировать вопрос, чтобы оно выбросило ненужное и разделило то, что надо разделять".
Я не знаю, о каком WishMaster речь, но факт тот, что на часть вопросов, где нет таких проблем, оно очень хорошо отвечает (вплоть до образцов кода/конфига с расшифровкой), а на часть — ужасно, и я вижу это именно на ситуациях, когда контексты описаны одинаковыми словами.
Джуна я таки знаю, как обучить.
Ну есть знакомые которые постоянно солят пиво. Сладкое они вроде не пьют, но я бы понял вопрос именно так. Причём сказал бы "да, бери то, что "меньше натрия"" — потому что при таком потреблении надо дать хотя бы такую помощь организму держать баланс солей.
Именно. Только надо было выбрать правильную алгебру :))
Тип данных uint2_t :)
Процессорных не видел. Программно — в kdb+ именно так и сделано.
В однобайтных, 0x80 = NaN, 0x7f = +Inf, 0x81 = -Inf.
Правда, там криво — если расширить до 2 байтов и выше, 0x7f переходит в 127. Намеренно недоработано для скорости обработки данных.
Есть ещё разные статьи с предложениями подобной арифметики как защитного подхода.
Нет, потому что натягивания не было. Вот спешка при написании ответа и следы больше разговорного стиля с повтором тезисов — было, за это вынужден просить прощения.
Обоснование же сути ответа — я по своему опыту общения с ChatGPT получил примерно те же выводы, что и автор. В этот раз конкретно на примере стоп-кранов это не повторилось, но в других случаях я регулярно получаю ответы системы "70% банальностей, 25% полезного и верного и 5% полного бреда", потому что оно скомпилировало именно так, не заметив какой-то тонкости.
А самое неприятное — это когда смешиваются более одного контекста, которые разделяются не одним словом, а длинными (от 3 слов и более) словосочетаниями, тогда оно вообще не может понять разницу и в выдаче даёт дикую смесь из всего найденного. Не буду вдаваться в детали, потому что подозрительно близко к NDA, но пример был про кастомный аналог make, который часть правил сборки отрабатывает сразу, а часть — откладывает на следующие стадии, так вот я с ~20 попыток не сумел найти, как ему объяснить, в какой из фаз сборки я пытаюсь задать свой порядок выполнения правил.
Человек бы понял максимум с 3-го повторения (ладно, с 5-го, если с бодуна).