Я думаю, что этого, в сочетании со скоординированным по времени, достаточно радикальным по содержанию, заявлением от самого мессенджера https://habr.com/ru/news/979764/, в сочетании с его принадлежностью корпорации Meta, которая уже признана в России экстремистской организацией и запрещена, будет достаточно, чтобы полностью мессенджер заблокировать в ближайшее время, как FB, по соответствующей статье, с навешиванием соответствующего ярлыка. При этом, у подписавшихся под этим иском есть большой риск прочувствовать на себе все последствия этого резкого изменения статуса в очень неприятной форме.
С рефакторингом на основе AST и верификацией есть проблема. Не существует алгоритмов верификации на данный момент, которые могут за обозримое время верифицировать на корректность произвольный конкурентный (concurrent) код. Там что-то связано с экспонентой в оценке сложности алгоритмов верификации от размера кодовой базы.
Я думаю тут проблема в гонке. Реализация качественного языкового сервера требует месяцев работы, а откладывать релиз MVP нельзя, т.к. надо скорее столбить нишу. Так что, скорее всего, что надо делать именно так, понимание было с самого начала, но, просто, временно заткнули хаками на ls+grep. Оно ведь и так тоже как-то работает...)
Слово может быть разбито на несколько токенов, плюс разметка и пунктуация, так что, токенов 4-5 в секунду там есть. Но, это первый запрос, так что, там еще может быть потрачено время время на инициализацию модели. Плюс, мы не знаем железа на котором оно работает....
Простите пожалуйста, а как вы юридически решаете вопрос признания mac-адреса устройства персональными данными?
Мак адрес точки доступа в большинстве случаев однозначно идентифицирует конкретного абонента. И, при сборе в связке с другими идентификаторами или координатами (геолокацией) является, видимо, ПД?
Локальное железо бывает разное. Если оперативки 256-512 гигов, то можно и 235B запустить на CPU или встроенном в ЦП NPU. И, оно будет работать, хоть и относительно медленно, хотя, это "медленно" будет более чем достаточно для такого использования. И, если у ЦП 128 ядер, то, и того быстрее.
Это ни в коем разе не энергоэффективно в сравнении с H100 GPU в облаке, но, H100 в ноутбук не воткнешь, а вот 256 гигов оперативки в ноутбуке со встроенным NPU на 40-50 TOps, - уже реальность.
Тут, как раз, нужен богатый выбор, чтобы пользователь мог выбрать лучшую локальную модель, которую тянет его железо. Или ту, которая его устраивает по балансу качества/скорости. Ведь, при аналогичной архитектуре, 8B, вероятно, будет лучше 1.7B. А 16B лучше 8B.
В ядре невозможно в принципе писать совсем без unsafe т.к. взаимодействие непосредственно с железом, к сожалению, требует прямой работы с памятью. Железо через DMA пишет в память что хочет и когда хочет и на безопасность Rust кладет большой, тяжелый болт.
Не... еще пока рано кричать "не работает ваш раст!".
А, вот, когда появится вторая уязвимость, уже можно будет экстраполировать по двум точкам, сравнивать с количеством найденных уязвимостей в C коде за тот же период, предварительно нормировав на количество строк кода на соответствующем языке.
Вот тут можно уже будет развести гораздо более аргументированный срач в комментах :-)
В принципе, спрос на простые, не требующие специальных навыков для установки и работы, умеющие работать локально, ассистенты определенно есть. Особенно, если удобная интеграция с ОС присутствует.
С другой стороны, хотелось бы иметь больший выбор локальных моделей:
Qwen3 (локальная 1,7В и подключаемая по API 235В)
Qwen3 1.7B, - это ни-о-чем. Но разработчики, вроде, обещают расширить список моделей.
Покупать NAS нет смысла, конечно. А вот старые NAS ими заполнять они вполне годятся.
У NVM-E SSD есть не очевидный скрытый фактор стоимости. Они сами по себе может и сравнялись с SATA SSD по стоимости, вот, только, стоимость одного порта в NAS системе на порядок выше.
Судя по тексту, путем Фэйсбука и Меты, которая уже признана в РФ экстремистской организацией и запрещена.
Я думаю, что этого, в сочетании со скоординированным по времени, достаточно радикальным по содержанию, заявлением от самого мессенджера https://habr.com/ru/news/979764/, в сочетании с его принадлежностью корпорации Meta, которая уже признана в России экстремистской организацией и запрещена, будет достаточно, чтобы полностью мессенджер заблокировать в ближайшее время, как FB, по соответствующей статье, с навешиванием соответствующего ярлыка. При этом, у подписавшихся под этим иском есть большой риск прочувствовать на себе все последствия этого резкого изменения статуса в очень неприятной форме.
Есть еще вариант с литьем/штамповкой. Начинку помещают внутрь формы и просто заливают/прессуют пластиком.
С рефакторингом на основе AST и верификацией есть проблема. Не существует алгоритмов верификации на данный момент, которые могут за обозримое время верифицировать на корректность произвольный конкурентный (concurrent) код. Там что-то связано с экспонентой в оценке сложности алгоритмов верификации от размера кодовой базы.
Осталось нанять сотню инженеров, которые будут осмысленно ревьюить по 1000+ строк в день, чтобы поспевать за этим ИИ.
Если же все это планируется в продакшен без ревью, то, это как-то, даже, не смешно, а, скорее, страшно...
Я думаю тут проблема в гонке. Реализация качественного языкового сервера требует месяцев работы, а откладывать релиз MVP нельзя, т.к. надо скорее столбить нишу. Так что, скорее всего, что надо делать именно так, понимание было с самого начала, но, просто, временно заткнули хаками на ls+grep. Оно ведь и так тоже как-то работает...)
Хэш-коллизия?
Это же первый запрос... А, при первом запросе там, наверняка, еще и промпт процессится...
Судя по профилю компании, они специализируются, помимо прочего, еще и на распознавании и генерации речи. Вероятно будут делать голосового помощника.
Так что, если токены будут генерироваться хоябы быстрее скорости человеческой речи, то для их юзкейза этого, вероятно, будет достаточно)
Слово может быть разбито на несколько токенов, плюс разметка и пунктуация, так что, токенов 4-5 в секунду там есть. Но, это первый запрос, так что, там еще может быть потрачено время время на инициализацию модели. Плюс, мы не знаем железа на котором оно работает....
Не много, но и на запуск оффлайн 235B сразу замахиваться не стоит. Но, в пределах 16B ассортимент было бы иметь не плохо)
С координатами?
Простите пожалуйста, а как вы юридически решаете вопрос признания mac-адреса устройства персональными данными?
Мак адрес точки доступа в большинстве случаев однозначно идентифицирует конкретного абонента. И, при сборе в связке с другими идентификаторами или координатами (геолокацией) является, видимо, ПД?
Локальное железо бывает разное. Если оперативки 256-512 гигов, то можно и 235B запустить на CPU или встроенном в ЦП NPU. И, оно будет работать, хоть и относительно медленно, хотя, это "медленно" будет более чем достаточно для такого использования. И, если у ЦП 128 ядер, то, и того быстрее.
Это ни в коем разе не энергоэффективно в сравнении с H100 GPU в облаке, но, H100 в ноутбук не воткнешь, а вот 256 гигов оперативки в ноутбуке со встроенным NPU на 40-50 TOps, - уже реальность.
Тут, как раз, нужен богатый выбор, чтобы пользователь мог выбрать лучшую локальную модель, которую тянет его железо. Или ту, которая его устраивает по балансу качества/скорости. Ведь, при аналогичной архитектуре, 8B, вероятно, будет лучше 1.7B. А 16B лучше 8B.
Это есть ни что иное, как достижение безопасности "методом страуса".
Но, unsafe уже есть :-D
В ядре невозможно в принципе писать совсем без unsafe т.к. взаимодействие непосредственно с железом, к сожалению, требует прямой работы с памятью. Железо через DMA пишет в память что хочет и когда хочет и на безопасность Rust кладет большой, тяжелый болт.
Когда научитесь писать код ядра на Rust совсем без unsafe, тогда поговорим.
А то, умные люди говорят, что это невозможно... :-)
Не... еще пока рано кричать "не работает ваш раст!".
А, вот, когда появится вторая уязвимость, уже можно будет экстраполировать по двум точкам, сравнивать с количеством найденных уязвимостей в C коде за тот же период, предварительно нормировав на количество строк кода на соответствующем языке.
Вот тут можно уже будет развести гораздо более аргументированный срач в комментах :-)
В принципе, спрос на простые, не требующие специальных навыков для установки и работы, умеющие работать локально, ассистенты определенно есть. Особенно, если удобная интеграция с ОС присутствует.
С другой стороны, хотелось бы иметь больший выбор локальных моделей:
Qwen3 1.7B, - это ни-о-чем. Но разработчики, вроде, обещают расширить список моделей.
Покупать NAS нет смысла, конечно. А вот старые NAS ими заполнять они вполне годятся.
У NVM-E SSD есть не очевидный скрытый фактор стоимости. Они сами по себе может и сравнялись с SATA SSD по стоимости, вот, только, стоимость одного порта в NAS системе на порядок выше.