Но нет. Нейронка это фиксированная последовательность вычислений. В LLM и генерации картинок специально подмешивают случайные значения на разных промежуточных шагах.
Думаю, нет проблем сделать детерминированный результат в рендеринге, если использовать фиксированный seed.
На вопрос про туннель вы ответили и поправили -- спасибо. Хотя я бы ожидал лучшей вычитки статьи перед публикацией.
А дальше вы отвечаете на вопрос, который я не задавал. При чем тут "код дистрибьютора" и прочие предложения идти и что-то проверять?
Статья интересная и техничная (это прекрасно), но читать противно (это ужасно). И вам об этом несколько разных участников сказали. Поэтому лучше принимайте сигналы и делайте выводы, а не пишите длинные водянистые ответы о том, что вас не спрашивали.
Если звучит резко, то так уж получается, пишу для робота же 😀
Так ведь если к вам на работу придет не стажёр, и не джун, а очень сеньористый сотрудник, то вы все равно на него потратите время на введение в курс дела и какое-то обучение, прежде чем новый человек начнет приносить пользу.
я на это смотрю так, что каждый отдельный маркер сам по себе не проблема. Они же из настоящих текстов всё-таки взялись. И вы, например, пару применили выше 😀 то есть люди так пишут и читают без проблем.
А вот когда маркеров много и часто, то получается такой очень "сгущеный" текст, который раздражает многих читателей.
Или возьмём произведения человеческого искусства (стихи, картины). Так как большинство людей не эксперты, то они оценивают произведения по своим ощущениям. Скажем, смотрят сто случайных человек на картину/стихотворение. Если 80/100 говорят окей, это скорее "хорошо". Если 20/100 говорят окей, то скорее нет. Если 50/50, но как-то неопределенно.
Так же и с текстами LLM. Если люди читают, и их ничего не бесит, но все нормально. А если бесит, надо искать способы подкручивать. Особенно учитывая то, что люди, похоже, более требовательны и строго к ошибкам роботов.
идентификатором владельца, который может занимать до 1024 байт. Проблема в том, что буфер ответа — всего 112 байт. Итого 1056 байт пишутся в 112-байтный буфер
Вероятно, ещё 32 байта взялись из прочих данных ответа сервера, но без пояснений выглядит либо как ошибка, либо как пропущенная информация.
А вот если бы вы код переписали на JavaScript, то для сайта и wasm бы не потребовался 😀 там же вообще никакой зависимости от консоли нет, судя по быстрому просмотру кода.
А по делу, очень прикольно, спасибо за идею и описанию.
Да, виноват, я их часто использую взаимозаменяемо. Потому что если нет каких-то особенных факторов (отпуск, много багов внезапно, и так далее), то velocity сойдёт за оценку capacity на ближайший спринт. Но может путать, наверное. Главное, чтобы команда понимала, о чем речь идёт.
Если промоутер не обратил внимания на пункт про конфеты, значит, он мог так же халатно отнестись к важным техническим требованиям, чуть ли не обрушением сцены. Коричневые M&M's были индикатором внимания к деталям.
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.
Вы, наверное, хотели сказать недетерминированная?
Но нет. Нейронка это фиксированная последовательность вычислений. В LLM и генерации картинок специально подмешивают случайные значения на разных промежуточных шагах.
Думаю, нет проблем сделать детерминированный результат в рендеринге, если использовать фиксированный seed.
На вопрос про туннель вы ответили и поправили -- спасибо. Хотя я бы ожидал лучшей вычитки статьи перед публикацией.
А дальше вы отвечаете на вопрос, который я не задавал. При чем тут "код дистрибьютора" и прочие предложения идти и что-то проверять?
Статья интересная и техничная (это прекрасно), но читать противно (это ужасно). И вам об этом несколько разных участников сказали. Поэтому лучше принимайте сигналы и делайте выводы, а не пишите длинные водянистые ответы о том, что вас не спрашивали.
Если звучит резко, то так уж получается, пишу для робота же 😀
я не мобильный разработчик и, вероятно, не в курсе полностью, но мне казалось, что невозможно сделать надёжный push без сервисов Гугла.
Все остальные решения будут показывать перманентное уведомление о фоновом процессе. Даже если проверять по таймеру, то примерно то же самое.
Есть ещё какие-то способы?
Во-первых, непонятно, что за туннель из предыдущего пункта.
Во-вторых, от этого фрагмента и всей статьи ужасно сквозит текстом, написанным ИИ.
Сейчас в западных компаниях обычно больше градаций должностей. Типичный набор Software Development Engineer должностей такой:
SDE I, SDE II, SDE II, Senior SDE, Staff SDE, Principal SDE, Distinguished SDE.
Плюс/минус вариации.
Как это сопоставить с джун, мидл, сеньор?
Неочевидное предложение, кмк. Для джуна и сеньора предполагается разный охват работы и уровень понимания системы в итоге.
Так ведь если к вам на работу придет не стажёр, и не джун, а очень сеньористый сотрудник, то вы все равно на него потратите время на введение в курс дела и какое-то обучение, прежде чем новый человек начнет приносить пользу.
Тоже, пока читал статью, все думал "А как же MobaXTerm?" -- а потом дочитал до места, где его называют слишком сложным для новичка.
я бы понял аргумент, что MobaXTerm не open source.
Garmin вроде продолжает делать браслеты Vivosmart, которые как раз посередине.
И не застревает нигде? Со старыми румбами проблема, что если хоть что-то мелкое лежит где-то, то обязательно намотает и застрянет.
я на это смотрю так, что каждый отдельный маркер сам по себе не проблема. Они же из настоящих текстов всё-таки взялись. И вы, например, пару применили выше 😀 то есть люди так пишут и читают без проблем.
А вот когда маркеров много и часто, то получается такой очень "сгущеный" текст, который раздражает многих читателей.
Или возьмём произведения человеческого искусства (стихи, картины). Так как большинство людей не эксперты, то они оценивают произведения по своим ощущениям. Скажем, смотрят сто случайных человек на картину/стихотворение. Если 80/100 говорят окей, это скорее "хорошо". Если 20/100 говорят окей, то скорее нет. Если 50/50, но как-то неопределенно.
Так же и с текстами LLM. Если люди читают, и их ничего не бесит, но все нормально. А если бесит, надо искать способы подкручивать. Особенно учитывая то, что люди, похоже, более требовательны и строго к ошибкам роботов.
Есть, конечно. Но утверждение, что systemd не популярен, звучит очень странно. Большинство массовых дистрибутивов идёт с systemd.
Например, данные https://commandlinux.com/statistics/systemd-vs-init-usage-statistics-across-distributions/
Не понимаю. Если systemd не популярен, то что тогда?
Так ведь если утилита в одном исходном файле, то borrow checker вы даже не заметите.
Вероятно, ещё 32 байта взялись из прочих данных ответа сервера, но без пояснений выглядит либо как ошибка, либо как пропущенная информация.
Вы в начале статьи привели в пример
которые на разработку ориентированы, а потом раз -- и сделали ассистента, который ходит по интернету.
я видел в конце статьи про планы сделать работу с локальными файлами, но все равно это немного другая цель по сравнению с, скажем, Claude.
А вот если бы вы код переписали на JavaScript, то для сайта и wasm бы не потребовался 😀 там же вообще никакой зависимости от консоли нет, судя по быстрому просмотру кода.
А по делу, очень прикольно, спасибо за идею и описанию.
Да, виноват, я их часто использую взаимозаменяемо. Потому что если нет каких-то особенных факторов (отпуск, много багов внезапно, и так далее), то velocity сойдёт за оценку capacity на ближайший спринт. Но может путать, наверное. Главное, чтобы команда понимала, о чем речь идёт.
И статью, похоже, тоже Клод писал 😀
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.