Вот этот Locust, как он, интересно, оценивает предел нагрузочной способности? Раз отказов не было, он как-то понимает, в какой момент надо остановиться и перестать повышать нагрузку. Интересно, по каким критериям он это делает?
И другой вопрос. Посылать и принимать HTTP-запросы - работа сравнимая. Locust ведь тоже мог упереться в пределы своей производительности. Благо что он написан на Питоне, исполняется на той же машине и тоже, вероятно, в одно ядро. Этот вариант в процессе тестирования не исключен.
В общем, к проведённому исследованию возникает много методологических вопросов...
Так выпьем же за то, чтоб наши желания совпадали с нашими возможностями (с)
И чтоб нам ничего за это не было!
Просто не попадалось задач, где по другому в принципе нельзя (или крайне нецелесообразно). Как, например, тут.
Попадались. Я делал BSP для самодельного чипа на основе ARM (самодельного не в том смысле, что его делали любители, а в том, что в этом и заключался бизнес конторы, в чиподелии).
Но это ж немного совсем ассемблера и ассемблер там простой. Притом, можно ведь по-разному писать. Я в этом BSP даже раскодирование номера IRQ из битовой маски сделал на Си. Но не наивным циклом, а явно расписанным двоичным поиском. И после того, как убедился, что gcc для подобного кода для этого процессора генерит, в общем-то, тот же ассемблер, что я руками бы написал.
Что до универсализма... Хороший подход. Только вот времена Гаусса и Леонардо да Винчи были давно, а любая универсальная вещь одинаково неудобна во всех вариантах в сравнении с узко специализированной.
Человек - исключение. Универсализм достигается не за счёт поверхностного знания по широкому кругу областей, а за счет предпочтения изучения принципов и идей, а не конкретных реализаций. Принципов и идей в ИТ гораздо меньше, чем конкретных реализаций.
Я всю жизнь с удовольствием занимаюсь системным программированием, в диапазоне от того, что делается с привлечением осциллографа и до весьма высокоуровневых вещей типа разборок с системой печати.
Желание слазить на уровень ассемблера пару раз присутствовало и ни разу в итоге не оправдывалось.
Я просто столяр-универсал, а не специалист по закручиванию шурупов определенного размера и с определенной формой шляпки в древесину определенного вида. Могу сделать полированный шкаф из морёного дуба, а могу - сосновый гроб.
В большинстве случаев, поддерживает (если я правильно понимаю, что такое HATEOAS).
Вы начинаете с URL, который представляет принтер. Когда вы создаёте Job, вы получаете URL этого Job-а, и т.д.
Состояние у IPP есть, но это не искусственная сессия, а состояние реальных дел. Например, пока принтер пережёвывает задание на печать (процесс вдумчивый и не быстрый, механика же), то состояние задания становится частью состояния принтера.
Для принтеров и сканеров, драйвера которых по сути фильтры - это допустимо
В некотором идеальном мире драйвера принтеров (но не сканеров) - это фильтры, которые преобразуют условный PostScript в условный URF или PWG-Raster.
В реальном мире там достаточно возни вокруг затыков аппаратуры. Причём понятие аппаратуры включает в себя заглюки firmware, которое там сложное и хрупкое. И там всё, как у людей (у прочих железок). Например, пока принтер "прогревается", он может весьма своеобразно реагировать на стандартные запросы.
Я писал драйвера сетевых карт, в т.ч, и Wi-Fi, с достаточно сложной логикой на хосте. Мне эта тема вполне знакома.
Проблема ровно в том, что у меня с вами очень разное понимание "системного программирования". В моем мире этим термином называют тот код, который НЕПОСРЕДСТВЕННО работает с аппаратурой
Я тоже работаю с аппаратурой, но только в последние несколько лет моя аппаратура - это принтеры и сканеры. Это такие довольно сложные железки, которые разговаривают с хостом в основном по сети или по USB.
Желание иметь 100% видимость и контроль на стыке железа и софта очень понятно. Непонятно, зачем для этого ассемблер. В целом, компилятору можно доверять, обычно всё же он нагенерирует то, что написано (в рамках свобод, гарантированных ему спецификацией языка). Мешают библиотечные автоматизмы, которые могут влиять на семантику действий.
В этом плане Go, например - вполне годный язык. Потому что от него можно добиться того, чтобы памятью он управлял, а в протокольные дела не лез, оставив видимость и контроль, сравнимые с ANSI C. Да, времянку он не всегда гарантирует, но мои устройства не настолько чувствительны к времянке.
C++ хорош тем, что можно не использовать все навороты языка одновременно
Это соображение хорошо работает, когда ведёшь проект в одиночку, или в команде принята дисциплина и единомыслие. И когда большая часть кода - своя, и не состоит в основном из legacy, авторы которого оставили свой неповторимый стиль в коде прежде, чем окончательно исчезнуть с радаров.
В реальности чаще получается ограничивать себя, но не соседа/соседний отдел/авторов библиотеки с гитхаба, которую вам посчастливилось использовать в проекте.
Мы обсуждаем нестандартное отношение упорядоченности
Автор статьи вообще утверждал, что комплексные числа нельзя упорядочить. Я оспариваю именно этот тезис. Получается, их можно упорядочить. Отношение порядка будет отличаться по свойствам от привычного, но в достаточной степени и будет похоже
Но это ведь не то же самое, что вообще отсутствие возможности их упорядочить, правда?
Если вопрос о точном формальном определении, то оно здесь не очень нужно. Для любого разумного определения будет свойственна подобная дуальность/конфликт.
Ну вот не соглашусь. Я даже привёл пример, для одних будет выразительнее Питон, благодаря его типадинамичности, а для других - Rust, благодаря тому, что в нём можно явно выразить владение объектом.
Вот этот Locust, как он, интересно, оценивает предел нагрузочной способности? Раз отказов не было, он как-то понимает, в какой момент надо остановиться и перестать повышать нагрузку. Интересно, по каким критериям он это делает?
И другой вопрос. Посылать и принимать HTTP-запросы - работа сравнимая. Locust ведь тоже мог упереться в пределы своей производительности. Благо что он написан на Питоне, исполняется на той же машине и тоже, вероятно, в одно ядро. Этот вариант в процессе тестирования не исключен.
В общем, к проведённому исследованию возникает много методологических вопросов...
Небось Go расползся по всем ядрам, а Питон грел только одно...
В абзаце же, а не во всём документе. Вряд ли ведь у кого документ на миллион строк, и все одним абзацем...
Но опять же, все они сводятся к определенным классам поездов, автобусов, самолётов и велосипедов, а не к конкретным номерам поездов
И чтоб нам ничего за это не было!
Попадались. Я делал BSP для самодельного чипа на основе ARM (самодельного не в том смысле, что его делали любители, а в том, что в этом и заключался бизнес конторы, в чиподелии).
Но это ж немного совсем ассемблера и ассемблер там простой. Притом, можно ведь по-разному писать. Я в этом BSP даже раскодирование номера IRQ из битовой маски сделал на Си. Но не наивным циклом, а явно расписанным двоичным поиском. И после того, как убедился, что gcc для подобного кода для этого процессора генерит, в общем-то, тот же ассемблер, что я руками бы написал.
Человек - исключение. Универсализм достигается не за счёт поверхностного знания по широкому кругу областей, а за счет предпочтения изучения принципов и идей, а не конкретных реализаций. Принципов и идей в ИТ гораздо меньше, чем конкретных реализаций.
Я всю жизнь с удовольствием занимаюсь системным программированием, в диапазоне от того, что делается с привлечением осциллографа и до весьма высокоуровневых вещей типа разборок с системой печати.
Желание слазить на уровень ассемблера пару раз присутствовало и ни разу в итоге не оправдывалось.
Я просто столяр-универсал, а не специалист по закручиванию шурупов определенного размера и с определенной формой шляпки в древесину определенного вида. Могу сделать полированный шкаф из морёного дуба, а могу - сосновый гроб.
В большинстве случаев, поддерживает (если я правильно понимаю, что такое HATEOAS).
Вы начинаете с URL, который представляет принтер. Когда вы создаёте Job, вы получаете URL этого Job-а, и т.д.
Состояние у IPP есть, но это не искусственная сессия, а состояние реальных дел. Например, пока принтер пережёвывает задание на печать (процесс вдумчивый и не быстрый, механика же), то состояние задания становится частью состояния принтера.
Сколько драйверов надо написать, чтобы из автолюбителя превратиться в автомеханика? :)
Я примерно про это и говорю. Угу, тем, что есть в компиляторах...
В некотором идеальном мире драйвера принтеров (но не сканеров) - это фильтры, которые преобразуют условный PostScript в условный URF или PWG-Raster.
В реальном мире там достаточно возни вокруг затыков аппаратуры. Причём понятие аппаратуры включает в себя заглюки firmware, которое там сложное и хрупкое. И там всё, как у людей (у прочих железок). Например, пока принтер "прогревается", он может весьма своеобразно реагировать на стандартные запросы.
Я писал драйвера сетевых карт, в т.ч, и Wi-Fi, с достаточно сложной логикой на хосте. Мне эта тема вполне знакома.
Переключатель задач на С я тоже, кстати, писал :)
Я тоже работаю с аппаратурой, но только в последние несколько лет моя аппаратура - это принтеры и сканеры. Это такие довольно сложные железки, которые разговаривают с хостом в основном по сети или по USB.
Желание иметь 100% видимость и контроль на стыке железа и софта очень понятно. Непонятно, зачем для этого ассемблер. В целом, компилятору можно доверять, обычно всё же он нагенерирует то, что написано (в рамках свобод, гарантированных ему спецификацией языка). Мешают библиотечные автоматизмы, которые могут влиять на семантику действий.
В этом плане Go, например - вполне годный язык. Потому что от него можно добиться того, чтобы памятью он управлял, а в протокольные дела не лез, оставив видимость и контроль, сравнимые с ANSI C. Да, времянку он не всегда гарантирует, но мои устройства не настолько чувствительны к времянке.
Это соображение хорошо работает, когда ведёшь проект в одиночку, или в команде принята дисциплина и единомыслие. И когда большая часть кода - своя, и не состоит в основном из legacy, авторы которого оставили свой неповторимый стиль в коде прежде, чем окончательно исчезнуть с радаров.
В реальности чаще получается ограничивать себя, но не соседа/соседний отдел/авторов библиотеки с гитхаба, которую вам посчастливилось использовать в проекте.
Интересно, в какой степени можно утверждать, что IPP (Internet Printing Protocol, RFC8010, RFC8011) - это RESTFul протокол?
Мы обсуждаем нестандартное отношение упорядоченности
Автор статьи вообще утверждал, что комплексные числа нельзя упорядочить. Я оспариваю именно этот тезис. Получается, их можно упорядочить. Отношение порядка будет отличаться по свойствам от привычного, но в достаточной степени и будет похоже
Но это ведь не то же самое, что вообще отсутствие возможности их упорядочить, правда?
Где здесь сказано, что умножать можно только на положительные числа?
Еще бы как-то убедиться, что выразительность и разрешимость могут быть отмерены по одной оси...
-1 < 0
умножим обе части на -1. Получилось
1 < 0
Упс!
Для обычных вещественных чисел:
Вроде как всё то же самое...
Ну вот не соглашусь. Я даже привёл пример, для одних будет выразительнее Питон, благодаря его типадинамичности, а для других - Rust, благодаря тому, что в нём можно явно выразить владение объектом.