я на это смотрю так, что каждый отдельный маркер сам по себе не проблема. Они же из настоящих текстов всё-таки взялись. И вы, например, пару применили выше 😀 то есть люди так пишут и читают без проблем.
А вот когда маркеров много и часто, то получается такой очень "сгущеный" текст, который раздражает многих читателей.
Или возьмём произведения человеческого искусства (стихи, картины). Так как большинство людей не эксперты, то они оценивают произведения по своим ощущениям. Скажем, смотрят сто случайных человек на картину/стихотворение. Если 80/100 говорят окей, это скорее "хорошо". Если 20/100 говорят окей, то скорее нет. Если 50/50, но как-то неопределенно.
Так же и с текстами LLM. Если люди читают, и их ничего не бесит, но все нормально. А если бесит, надо искать способы подкручивать. Особенно учитывая то, что люди, похоже, более требовательны и строго к ошибкам роботов.
идентификатором владельца, который может занимать до 1024 байт. Проблема в том, что буфер ответа — всего 112 байт. Итого 1056 байт пишутся в 112-байтный буфер
Вероятно, ещё 32 байта взялись из прочих данных ответа сервера, но без пояснений выглядит либо как ошибка, либо как пропущенная информация.
А вот если бы вы код переписали на JavaScript, то для сайта и wasm бы не потребовался 😀 там же вообще никакой зависимости от консоли нет, судя по быстрому просмотру кода.
А по делу, очень прикольно, спасибо за идею и описанию.
Да, виноват, я их часто использую взаимозаменяемо. Потому что если нет каких-то особенных факторов (отпуск, много багов внезапно, и так далее), то velocity сойдёт за оценку capacity на ближайший спринт. Но может путать, наверное. Главное, чтобы команда понимала, о чем речь идёт.
Если промоутер не обратил внимания на пункт про конфеты, значит, он мог так же халатно отнестись к важным техническим требованиям, чуть ли не обрушением сцены. Коричневые M&M's были индикатором внимания к деталям.
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.
Перевод ещё таки страдает. Выбрал En, а часть сообщений остались на русском: метка "Вы", значение "Среднее" на столе, "Ожидание игроков" , ну и "сервис от создателей" внизу.
sqlite сильно пессимизирует и обобщает лет так на 15 😀
Да, блокировки в NFSv3 (которые отдельный протокол NLM, да и сам NFSv3 без сессий) действительно плохо работают вместе с NAT, фаерволами, роумингом wifi со сменой IP адресов, засыпанием ноутбуков. Если таких проблем нет, то даже NFSv3/NLM работает надёжно.
Но современные Linux-ы давно по умолчанию используют NFSv4, в котором блокировки уже часть протокола.
Про Windows faq ссылается на FAT и косяки реализации. Это тоже уже устарело до смешного. Любой современный Windows с NTFS и SMBv3 поддерживает блокировки без каких-либо проблем давно. А с persistent handles клиенты даже перезагрузки сервера переживут.
Верю, скажем, что когда-то были баги в Samba. Но сейчас уже давно ребята из SerNet хорошо работают над Samba. Если только у вас не файловый сервер на каком-то дремучем NAS, то проблем не будет.
Так что сетевые диски точно не нужно запрещать. Предупреждение можно, если хотите 😀
Единственно, если не уже (я не смотрел код), то стоит I/O делать асинхронно, чтобы основной UI не замирал, если вдруг сетевой диск затупил.
Для тех, кто не понял, поясните, пожалуйста 😀
И не застревает нигде? Со старыми румбами проблема, что если хоть что-то мелкое лежит где-то, то обязательно намотает и застрянет.
я на это смотрю так, что каждый отдельный маркер сам по себе не проблема. Они же из настоящих текстов всё-таки взялись. И вы, например, пару применили выше 😀 то есть люди так пишут и читают без проблем.
А вот когда маркеров много и часто, то получается такой очень "сгущеный" текст, который раздражает многих читателей.
Или возьмём произведения человеческого искусства (стихи, картины). Так как большинство людей не эксперты, то они оценивают произведения по своим ощущениям. Скажем, смотрят сто случайных человек на картину/стихотворение. Если 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 на ближайший спринт. Но может путать, наверное. Главное, чтобы команда понимала, о чем речь идёт.
И статью, похоже, тоже Клод писал 😀
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.
Перевод ещё таки страдает. Выбрал En, а часть сообщений остались на русском: метка "Вы", значение "Среднее" на столе, "Ожидание игроков" , ну и "сервис от создателей" внизу.
Не знаю, как распространено это заблуждение, но столица штата Вашингтон это город Олимпия, а не Сиэтл.
https://en.wikipedia.org/wiki/Olympia,_Washington
Нет, может быть составным 😀 (не удержался)
sqlite сильно пессимизирует и обобщает лет так на 15 😀
Да, блокировки в NFSv3 (которые отдельный протокол NLM, да и сам NFSv3 без сессий) действительно плохо работают вместе с NAT, фаерволами, роумингом wifi со сменой IP адресов, засыпанием ноутбуков. Если таких проблем нет, то даже NFSv3/NLM работает надёжно.
Но современные Linux-ы давно по умолчанию используют NFSv4, в котором блокировки уже часть протокола.
Про Windows faq ссылается на FAT и косяки реализации. Это тоже уже устарело до смешного. Любой современный Windows с NTFS и SMBv3 поддерживает блокировки без каких-либо проблем давно. А с persistent handles клиенты даже перезагрузки сервера переживут.
Верю, скажем, что когда-то были баги в Samba. Но сейчас уже давно ребята из SerNet хорошо работают над Samba. Если только у вас не файловый сервер на каком-то дремучем NAS, то проблем не будет.
Так что сетевые диски точно не нужно запрещать. Предупреждение можно, если хотите 😀
Единственно, если не уже (я не смотрел код), то стоит I/O делать асинхронно, чтобы основной UI не замирал, если вдруг сетевой диск затупил.
Расскажите, чем вызваны эти опасения.
Интересно, почему переехали на UpNote, а не купили Obsidian Sync?
и даже
Строго говоря, это не обновление ресурса, потому что в ресурсе вряд ли есть поля
opиvalue. Это действия, которые лучше делать через POST.С PUT и PATCH обычно следуют правилу, что результат GET можно отправить в PUT или PATCH.
Но даже в вашем примере (increment через POST) можно защититься от повторного изменение с помощью etag и if-match.
Думаю, они на рынок США нацелены сейчас, а там такая цена может пойти.