Так-с, важный вопрос. Каким облачным хранилищем вы пользуетесь? Я в 22 году переехал в Яндекс Диск из-за того, что не мог оплачивать Google Drive. Чувствую, что пришло время переезжать в другое место.
😁3❤2🔥1💯1
yet another dev
Так-с, важный вопрос. Каким облачным хранилищем вы пользуетесь? Я в 22 году переехал в Яндекс Диск из-за того, что не мог оплачивать Google Drive. Чувствую, что пришло время переезжать в другое место.
Мы выбрали Google Drive. У них более менее адекватный ценник и, в целом, знакомая экосистема. Хочу мигрировать данные асап. А серваком можно заняться позднее.
Я ещё рассматривал Proton, но у них плохая интеграция с rclone, да и ценник почти в 2 раза выше, чем у Google.
Подписка на Google One 2 Тб стоит $100 в год. Хранилище можно пошарить с членами семьи. В итоге, выходит где-то 2-3 раза дороже, чем Яндекс Диск.
Данные мигрирую при помощи rclone. Интеграция с Яндексом у него прекрасная. А вот с Google пришлось повозиться – доступ к Drive только через API, который включается через Google Cloud Console, а ещё там надо настраивать креды и т.д.
Кстати, важный момент о котором я не знал. В мобильном приложении Яндекс Диска есть функция автозагрузки фото и видео. И они могут загружаться в так называемое "безлимитное хранилище".
Прикол в том, что это безлимитное хранилище существует отдельно от Яндекс Диска и поэтому rclone его не видит.
Я вчера потратил несколько часов перенося вручную фотографии по 500 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.
Я ещё рассматривал Proton, но у них плохая интеграция с rclone, да и ценник почти в 2 раза выше, чем у Google.
Подписка на Google One 2 Тб стоит $100 в год. Хранилище можно пошарить с членами семьи. В итоге, выходит где-то 2-3 раза дороже, чем Яндекс Диск.
Данные мигрирую при помощи rclone. Интеграция с Яндексом у него прекрасная. А вот с Google пришлось повозиться – доступ к Drive только через API, который включается через Google Cloud Console, а ещё там надо настраивать креды и т.д.
Кстати, важный момент о котором я не знал. В мобильном приложении Яндекс Диска есть функция автозагрузки фото и видео. И они могут загружаться в так называемое "безлимитное хранилище".
Прикол в том, что это безлимитное хранилище существует отдельно от Яндекс Диска и поэтому rclone его не видит.
Я вчера потратил несколько часов перенося вручную фотографии по 500 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.
Мне удалось скопировать в Google Drive практически все данные с Яндекс Диска. Осталось только 3 файла, которые всё ещё недоступны.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
🫡4😱3👀3👍2
Что не так с маркировкой ИИ от Яндекс Музыки
На прошлых выходных появилось настроение поработать над Slopless. Как раз в GitHub предложили в расширении учитывать маркировку от Яндекса. Этим я и занялся.
За выходные я сравнил разметку Slopless и Яндекс для всех треков начиная с 2024 года, у которых есть хотя бы один лайк.
По оценке Slopless, 27% из проверенных треков созданы с помощью ИИ, а по оценке Яндекса — таких треков не более 18%.
Оценка Яндекса более комплексная. Там есть 3 категории:
- возможно ИИ;
- частично ИИ;
- полностью ИИ.
Две последние категории основаны на данных от дистрибьюторов. Некоторые из них добровольно собирают и передают информацию о том, как был использован ИИ при создании музыки: для аранжировки, для вокала или же трек сгенерирован полностью. Категория «возможно, ИИ» — это результат работы детектора ИИ от Яндекса.
Но, как я уже писал ранее, дистрибьюторы не обязаны передавать информацию об использовании ИИ, и многие этого не делают. В особенности создатели виртуальных ИИ-артистов.
Детектор ИИ от Яндекса не маркирует всю музыку таких исполнителей. А из-за того что маркировка Яндекса спрятана в метаданных треков, для пользователей эта информация труднодоступна.
Вот примеры некоторых таких исполнителей:
- Детские колыбельные
- Музыка для сна
- Музыка для сна младенцев
- Музыка для сна малыша
- КОЛЫБЕЛЬНЫЕ
- Музыка для медитации
- Спокойная фоновая музыка
- Iren Lullaby
Попробуйте там найти промаркированные треки.
#нейромузыка@yet_another_dev
На прошлых выходных появилось настроение поработать над Slopless. Как раз в GitHub предложили в расширении учитывать маркировку от Яндекса. Этим я и занялся.
За выходные я сравнил разметку Slopless и Яндекс для всех треков начиная с 2024 года, у которых есть хотя бы один лайк.
По оценке Slopless, 27% из проверенных треков созданы с помощью ИИ, а по оценке Яндекса — таких треков не более 18%.
Оценка Яндекса более комплексная. Там есть 3 категории:
- возможно ИИ;
- частично ИИ;
- полностью ИИ.
Две последние категории основаны на данных от дистрибьюторов. Некоторые из них добровольно собирают и передают информацию о том, как был использован ИИ при создании музыки: для аранжировки, для вокала или же трек сгенерирован полностью. Категория «возможно, ИИ» — это результат работы детектора ИИ от Яндекса.
Но, как я уже писал ранее, дистрибьюторы не обязаны передавать информацию об использовании ИИ, и многие этого не делают. В особенности создатели виртуальных ИИ-артистов.
Детектор ИИ от Яндекса не маркирует всю музыку таких исполнителей. А из-за того что маркировка Яндекса спрятана в метаданных треков, для пользователей эта информация труднодоступна.
Вот примеры некоторых таких исполнителей:
- Детские колыбельные
- Музыка для сна
- Музыка для сна младенцев
- Музыка для сна малыша
- КОЛЫБЕЛЬНЫЕ
- Музыка для медитации
- Спокойная фоновая музыка
- Iren Lullaby
Попробуйте там найти промаркированные треки.
#нейромузыка@yet_another_dev
👍7
Статический анализ кода и ИИ-разработка
Мы все уже не раз видели, как какая-то компания переписала проект с языка X на Rust при помощи ИИ. За примерами ходить не надо:
1. Microsoft переписали рантайм Copilot CLI с TypeScript на Rust.
2. Anthropic переписали рантайм Bun с Zig на Rust.
После моей истории с исправлением ошибок SonarQube при помощи ИИ, я начал догадываться почему для переписывания выбирают Rust – у него очень строгий компилятор, который просто не даст собраться проекту, если что-то не так.
Но похожего поведения можно добиться и с C#, например, а затем использовать такой подход не только для переписывания существующих проектов, но и для написания нового кода.
После исправления ошибок SonarQube я поэкспериментировал с возможностями .NET: добавил .editorconfig, указал там правила и сделал так, чтобы они вызывали ошибку при сборке.
Например, сейчас Microsoft рекомендует использовать LoggerAttribute для высокопроизводительного логирования. Но если жёстких ограничений нет, то ИИ всё равно может писать про старому.
Включив проверку правила CA1873, можно добиться от агента нужного кода. У него просто не будет другого выбора, кроме как писать правильный код.
Иначе говоря, детерминированность кода зависит от строгости анализаторов. Чем больше правил выбрасывают ошибки при сборке, тем более детерминированный будет результат.
Но такие проверки кода помогают определить только «форму» кода и не влияют на «смысл», то есть бизнес логику. Проверка бизнес логики – другая задача и должна решаться следующим уровнем проверок, а именно тестами.
#программирование@yet_another_dev
Мы все уже не раз видели, как какая-то компания переписала проект с языка X на Rust при помощи ИИ. За примерами ходить не надо:
1. Microsoft переписали рантайм Copilot CLI с TypeScript на Rust.
2. Anthropic переписали рантайм Bun с Zig на Rust.
После моей истории с исправлением ошибок SonarQube при помощи ИИ, я начал догадываться почему для переписывания выбирают Rust – у него очень строгий компилятор, который просто не даст собраться проекту, если что-то не так.
Но похожего поведения можно добиться и с C#, например, а затем использовать такой подход не только для переписывания существующих проектов, но и для написания нового кода.
После исправления ошибок SonarQube я поэкспериментировал с возможностями .NET: добавил .editorconfig, указал там правила и сделал так, чтобы они вызывали ошибку при сборке.
Например, сейчас Microsoft рекомендует использовать LoggerAttribute для высокопроизводительного логирования. Но если жёстких ограничений нет, то ИИ всё равно может писать про старому.
Включив проверку правила CA1873, можно добиться от агента нужного кода. У него просто не будет другого выбора, кроме как писать правильный код.
Иначе говоря, детерминированность кода зависит от строгости анализаторов. Чем больше правил выбрасывают ошибки при сборке, тем более детерминированный будет результат.
Но такие проверки кода помогают определить только «форму» кода и не влияют на «смысл», то есть бизнес логику. Проверка бизнес логики – другая задача и должна решаться следующим уровнем проверок, а именно тестами.
#программирование@yet_another_dev
👍5✍2🔥1
😁9