Совершенно верно. Все манипулируют экспонентой, потому что так модно. но тут, скорее всего, по моим наблюдениям, идёт речь о функции 1/x , а вот у неё конец как раз есть.
Больше, гораздо больше. там ведь ещё надо учесть много чего, фабрики соединительные скоростные между картами, шасси, свичи. Вообщем хорошо поиздевались. Квантизируйте, господа!
У них есть отдельный продукт, называется coding helper, который позволяет использовать claude code, opencode, crush и factory droid в качестве cli-фронтенда. Тулза откровенно хакерская, если не сказать - пиратская. когда её останавливаешь, она удаляет свой основной запускаемый скрипт из bin - директории node_modules, надо заново переустанавливать. Клич тоже заново вводить. А так-всё работает, я проверил. GLM-5 действительно, работает только на MAX. генерируемый код из одного и того же промпта на 99% бьётся с claude 4.6
Ну, Picochip PC-302 совсем не проприетарный baseband, меня даже девбоард и компилятор для него есть. Стоило это удовольствие в 2005-м где-то $200k вместе с референс-дизайном базовой станции wimax 2004. это матрица из 100 маленьких процессоров специально для baseband-дизайнов.
Что-то мне подсказывает, что появись claude в 70-х годах, его бы обязательно научили програпммировать на cobol, awk, fortran, pascal, c. потом иерациоонно бы добавили modula2/modula3/turbopascal/limbo. Однако что помешала распарссить этот файл не awk, а pandas, который claude знает очень хорошо? И да, есть ведь ещё язык brainfuck, в котором, мне кажется, claude тоже "поплывёт".
Что касается verilog/VHDL. мне кажется проблема здесь кроется в крайне малой кодовой базе в открытом доступе для обучения.
Он учёл фидбек инвесторов. А принципы подачи материала, не оговоренные инвесторами - это авторские принципы. Они заключаются в репрезентации автором в голове психологических особенностей, и, возможно, характера инвесторов. В чём проблема, я не понимаю???
Забавно. Очень забавно. И categorize.py тоже понравился. Вот бы это всё применить к 10000 букмарков в моих 3-х браузерах. Первую итерацию я прошёл. Букмарки-то лежат теперь в obsidian. Причём только нужные. А вот пройтись по ним, как по документам, чтобы категоризировать...
Мне кажется, что тут смешались в кучу кони, люди. LLM-модель никогда не способна была действовать абсолютно аналитически, и принимать решения на основе анализа данных. Здесь (как костыль) приходит RAG. Вот ты на вход первичной модели подаёшь свой Retrieval, основанный на линейной математике, Марковских, Байеса, Калмана с твоими коэффициентами, ещё чего-то-там, потом получаешь выдачи вторичной модели на основе промпта, который ей сгенерирован. Мне кажется, что главное заблуждение общения с моделями заключается в том, что она должна за тебя "подумать". пока что нет. думай сам. дай данные для вторичной аналитики. Потом, но основе обоснованных практик RAG с очень длинным контекстом можно переобучить в модельки. Не надо ждать ничего большего от пре-интеллекта. Ему только ещё предстоит появиться.
Да вы всё верно говорите, но только одно непонятно. Зачем математические формулы переводить на русский, если их можно скопипастить? Как и графики. Тем более что всё это в разных форматах лежит на гитхабе. Что такого английского в математических формулах?
Полностью согласен. Только не DRM, а DRI. С момента появления первых композитных менеджеров окон эпоха протокола X11 прошла насовсем. В какой-то мере программы ещё продолжали общаться с Xlib, но уж точно не с X11 protocol. А это было очень давно. Это относилось даже к шрифтам. И с тех пор именно API DRI определял вектор развития оконных интерфейсов *nix. А поскольку стандарта DRI не существовало, тав вендоры работали с extensions, кто во что горазд. Вот и появилась идея создания низкоуровневого композитного менеджера, такого, как Wayland, а уж над ним конструкции низкоуровневого графического API, Vulcan. Кстати, именно после появления концепции связки Wayland/Vulkan, Apple задумалась о создании своего собственного низкоуровневого API (Metal). Apple, кстати, даже участвовала в консорциуме Vulcan, потом отвалилась от него.
Ни DRI, ни Wayland, ни Vulcan не имеют сетевого протокола как такового, потому что это физически нереализуемо с разумным уровнем полезности.
Так что темы, которая затрагивает эта статья прокисли году этак в 2006-м. Кстати, автор не отметил следующих особенностей/недостатков протокола:
Работа со шрифтами. Для нормальной работы шрифты на клиенте и сервере должны в точности совпадать. В протоколе не было механизма ни загрузки шрифтов, ни их предварительной передачи/кэширования.
Абсолютно перегруженный нелепыми понятиями и уровнями keyboard/mouse mapping, который никогда по-человечески не работал. Для этого они были вынуждены делать даже костыли через Dbus с пробросом сигнализации сторонним менеджерам мэппинга.
Ну и про DRI ничего не было сказано, хотя, как я сказал, года с 2006-го, X11 - это всего лишь оболочка над DRI для выделения границ окон.
Статья хорошая, спору нет. Но в в данном конкретном случае это решение избыточно примерно как микроскоп по отношению к гвоздям. достаточно набрать, например, в google play фразу "http proxy server", скачать тот, у кого меньше рекламы. Прописать на дивайте прокси. И радоваться. Там есть как http-прокси, так и socs, и даже прозрачные.
И да, как только явление станет более-менее массовым, зашейпят на раз. Ведь шейпят же и так "ping -f". Так что как эксперимент для себя - норм, как рабочее решение - ни о чём.
Я считаю, что GraphQL - крайне небезопасная спецификация с точки зрения security. Какие стандартные способы Spring (либо какие-то иные) существуют для авторизации запросов GraphQL. Нигде развития этой темы я серьёзно не видел, начиная с Метеора (Apollo), и кончая вот этими костылями. Да, все давно с помощью Spring Data научились прозрачно мэппить репозитории Spring Data на какие-то эндпоинты. Sprind Data REST (HATEOAS), OpenAPI (Swagger), odata (Olingo2). Но там речь идёт о семантике REST-endpoints, для которых подходит как стандартная Sping Security, так и куча других костылей. Как быть в случае GraphQL, природа не подсказывает. А чем он вообще лучше SQL через http(s)? За исключением агрегации запросов? Есть ли в java какие-то способы/фреймворки/библиотеки, поддерживающие солидную авторизацию (не аутентификацию) запросов с помощью GraphQL, и исключающие injection?
Не могу себе это представить. Это о каких языках вы говорите по отношению к Python?
Не могу представить себе более лаконичного решения любой задачи, чем на Python.
Приведите, пожалуйста, в пример эти нескольких строк кода. Просто интересно стало…
А всё потому, что вы не использовали дополнительную прокладку в виде service над репозиториями. Нсли бы она была, красноты стало бы существенно меньше.
Совершенно верно. Все манипулируют экспонентой, потому что так модно. но тут, скорее всего, по моим наблюдениям, идёт речь о функции 1/x , а вот у неё конец как раз есть.
diy inference за 5М руб. так себе удовольствие
Больше, гораздо больше. там ведь ещё надо учесть много чего, фабрики соединительные скоростные между картами, шасси, свичи. Вообщем хорошо поиздевались. Квантизируйте, господа!
А надо claude в качестве code review/тестировщика привлечь. И пусть они рубятся по кругу до полного счастья.
У них есть отдельный продукт, называется coding helper, который позволяет использовать claude code, opencode, crush и factory droid в качестве cli-фронтенда. Тулза откровенно хакерская, если не сказать - пиратская. когда её останавливаешь, она удаляет свой основной запускаемый скрипт из bin - директории node_modules, надо заново переустанавливать. Клич тоже заново вводить. А так-всё работает, я проверил. GLM-5 действительно, работает только на MAX. генерируемый код из одного и того же промпта на 99% бьётся с claude 4.6
Ну, Picochip PC-302 совсем не проприетарный baseband, меня даже девбоард и компилятор для него есть. Стоило это удовольствие в 2005-м где-то $200k вместе с референс-дизайном базовой станции wimax 2004. это матрица из 100 маленьких процессоров специально для baseband-дизайнов.
Что-то мне подсказывает, что появись claude в 70-х годах, его бы обязательно научили програпммировать на cobol, awk, fortran, pascal, c. потом иерациоонно бы добавили modula2/modula3/turbopascal/limbo. Однако что помешала распарссить этот файл не awk, а pandas, который claude знает очень хорошо? И да, есть ведь ещё язык brainfuck, в котором, мне кажется, claude тоже "поплывёт".
Что касается verilog/VHDL. мне кажется проблема здесь кроется в крайне малой кодовой базе в открытом доступе для обучения.
Он учёл фидбек инвесторов. А принципы подачи материала, не оговоренные инвесторами - это авторские принципы. Они заключаются в репрезентации автором в голове психологических особенностей, и, возможно, характера инвесторов. В чём проблема, я не понимаю???
Забавно. Очень забавно. И categorize.py тоже понравился. Вот бы это всё применить к 10000 букмарков в моих 3-х браузерах. Первую итерацию я прошёл. Букмарки-то лежат теперь в obsidian. Причём только нужные. А вот пройтись по ним, как по документам, чтобы категоризировать...
Мне кажется, что тут смешались в кучу кони, люди. LLM-модель никогда не способна была действовать абсолютно аналитически, и принимать решения на основе анализа данных. Здесь (как костыль) приходит RAG. Вот ты на вход первичной модели подаёшь свой Retrieval, основанный на линейной математике, Марковских, Байеса, Калмана с твоими коэффициентами, ещё чего-то-там, потом получаешь выдачи вторичной модели на основе промпта, который ей сгенерирован. Мне кажется, что главное заблуждение общения с моделями заключается в том, что она должна за тебя "подумать". пока что нет. думай сам. дай данные для вторичной аналитики. Потом, но основе обоснованных практик RAG с очень длинным контекстом можно переобучить в модельки. Не надо ждать ничего большего от пре-интеллекта. Ему только ещё предстоит появиться.
Декодировать может любой референсный декодер. С аппаратным ускорением, либо нет. Вся статья была посвящена кодированию.
Да вы всё верно говорите, но только одно непонятно. Зачем математические формулы переводить на русский, если их можно скопипастить? Как и графики. Тем более что всё это в разных форматах лежит на гитхабе. Что такого английского в математических формулах?
А коммутаторы со стыками PRI и синхронными матрицами коммутации они что, аналоговые, что ли?
Правильнее было бы сказать "теперь построены на коммутации пакетов, вместо коммутации каналов"
Полностью согласен. Только не DRM, а DRI. С момента появления первых композитных менеджеров окон эпоха протокола X11 прошла насовсем. В какой-то мере программы ещё продолжали общаться с Xlib, но уж точно не с X11 protocol. А это было очень давно. Это относилось даже к шрифтам. И с тех пор именно API DRI определял вектор развития оконных интерфейсов *nix. А поскольку стандарта DRI не существовало, тав вендоры работали с extensions, кто во что горазд. Вот и появилась идея создания низкоуровневого композитного менеджера, такого, как Wayland, а уж над ним конструкции низкоуровневого графического API, Vulcan. Кстати, именно после появления концепции связки Wayland/Vulkan, Apple задумалась о создании своего собственного низкоуровневого API (Metal). Apple, кстати, даже участвовала в консорциуме Vulcan, потом отвалилась от него.
Ни DRI, ни Wayland, ни Vulcan не имеют сетевого протокола как такового, потому что это физически нереализуемо с разумным уровнем полезности.
Так что темы, которая затрагивает эта статья прокисли году этак в 2006-м. Кстати, автор не отметил следующих особенностей/недостатков протокола:
Работа со шрифтами. Для нормальной работы шрифты на клиенте и сервере должны в точности совпадать. В протоколе не было механизма ни загрузки шрифтов, ни их предварительной передачи/кэширования.
Абсолютно перегруженный нелепыми понятиями и уровнями keyboard/mouse mapping, который никогда по-человечески не работал. Для этого они были вынуждены делать даже костыли через Dbus с пробросом сигнализации сторонним менеджерам мэппинга.
Ну и про DRI ничего не было сказано, хотя, как я сказал, года с 2006-го, X11 - это всего лишь оболочка над DRI для выделения границ окон.
Статья хорошая, спору нет. Но в в данном конкретном случае это решение избыточно примерно как микроскоп по отношению к гвоздям. достаточно набрать, например, в google play фразу "http proxy server", скачать тот, у кого меньше рекламы. Прописать на дивайте прокси. И радоваться. Там есть как http-прокси, так и socs, и даже прозрачные.
И да, как только явление станет более-менее массовым, зашейпят на раз. Ведь шейпят же и так "ping -f". Так что как эксперимент для себя - норм, как рабочее решение - ни о чём.
Я считаю, что GraphQL - крайне небезопасная спецификация с точки зрения security. Какие стандартные способы Spring (либо какие-то иные) существуют для авторизации запросов GraphQL. Нигде развития этой темы я серьёзно не видел, начиная с Метеора (Apollo), и кончая вот этими костылями. Да, все давно с помощью Spring Data научились прозрачно мэппить репозитории Spring Data на какие-то эндпоинты. Sprind Data REST (HATEOAS), OpenAPI (Swagger), odata (Olingo2). Но там речь идёт о семантике REST-endpoints, для которых подходит как стандартная Sping Security, так и куча других костылей. Как быть в случае GraphQL, природа не подсказывает. А чем он вообще лучше SQL через http(s)? За исключением агрегации запросов? Есть ли в java какие-то способы/фреймворки/библиотеки, поддерживающие солидную авторизацию (не аутентификацию) запросов с помощью GraphQL, и исключающие injection?
Не могу представить себе более лаконичного решения любой задачи, чем на Python.
Приведите, пожалуйста, в пример эти нескольких строк кода. Просто интересно стало…
А всё потому, что вы не использовали дополнительную прокладку в виде service над репозиториями. Нсли бы она была, красноты стало бы существенно меньше.