Xeon / EPYC это обычные CPU, поэтому скорость генерации токенов будет слишком медленная, по несколько секунд на одно слово, тогда как Apple Silicon это несколько слов в секунду. Энергопотребление тоже не в пользу Intel / AMD.
Фактически, компьютеры от Apple - единственные на рынке с большим объемом RAM памяти, которая доступна не только CPU, но и GPU. В общем, это и есть unified memory и это идеально подходит для локального LLM inference: чаты, кодинг.
Вместо git push --force лучше всегда делать git push --force-with-lease. В чем разница? Допустим вы с Васей работаете над одной общей веткой и хотите исправить текст нового коммита, который вы только что отправили, но если Вася в это время отправил свой коммит, то git push --force просто молча выкинет его коммит из истории на сервере, потому что ваш репозиторий его не видит. Тогда как git push --force-with-lease запрещает переписывание ветки, если там есть новые чужие коммиты. Я лично использую алиас git pf.
Сделать сразу грамотную архитектуру, писать только качественный код обычно нереально. Настоящие бизнес требования, которые приносят прибыль, находятся только после множества релизов.
Согласен, я сам разработчик, так всегда и происходит. Только я никого не оправдываю и не обвиняю. Замедление скорости доставки под грузом старой архитектуры и качества кода - это, к сожалению, нормально. Бизнес редко выбирает риск переписывания системы с нуля.
Это практически все случаи, когда кому-то платят деньги за написание кода. В бизнесе компания вынуждена зарабатывать деньги, а расходы на разработку ПО - это большая и серьезная статья расходов, которую она стремится минимизировать. Только корпорации могут себе позволить такие большие затраты.
Именно! Инженерам нужен длинный горизонт планирования, но в бизнесе ситуация постоянно меняется и планы тоже. Бизнесу нужны постоянные эксперименты с фичами, чтобы выжить, а инженер хочет неизменность функциональных требований. Это неизбежное фундаментальное противоречие.
Объяснение от обратного. Вот где реально необходимо писать качественный код? Когда цена необратимой ошибки очень высока: медицинское оборудование, ядро платежных систем, управление самолетом и т.д. И тут есть существенный минус: необходимо много времени на серьезный code review, глубокое тестирование перед релизом. В типичном корпоративном бизнесе все наоборот: скорость доставки на порядок важнее, чем отсутствие проблем в коде или архитектуре. Таким образом, это не является существенной проблемой самого бизнеса.
Какой абсолютный минимум объем RAM нужен для такого учебного проекта? И как насчёт сборки под ARM с запуском на QEMU и на физическом железе типа Raspberry?
Недавно мне надо было написать скрипт для docker alpine и я так и не смог нагуглить какой-нибудь нормальный cheat sheet для sh, так как в выдаче поиска был один только bash. Пришлось добавить apk add --no-cache bash.
Кто-нибудь может поделиться ссылкой на удобный справочник по sh?
У меня есть несколько доменных имён, которые указывают на 127.0.0.1. Используются для разработки, в частности чтобы иметь настоящий TLS сертификат для localhost, чтобы браузер сразу открывал веб приложение без лишних телодвижений.
Я сделал немного по-другому. Купил домен у google domain, для примера пусть это будет "supermail.com". В его админке сделал бесплатный wildcard email forwarding на свой секретный email
*@supermail.com => secret@gmail.com
Таким образом при регистрации где-либо я просто указываю абсолютно любой email на домене, например "uber@supermail.com", и без проблем получаю входящие письма на обычный gmail.
Отправить письмо как "uber@supermail.com" тоже несложно. Достаточно один раз подтвердить домен в каком-нибудь email delivery service и использовать его бесплатный план. В gmail есть настройка "send mail as" где можно создать любой исходящий адрес (alias), указав в моем случае "smtp.sendgrid.net", "apikey" и пароль.
Если на какой-то адрес начинает идти спам, то его можно полностью исключить, сделав для него google domain email forwarding на другой email, например мне приходил постоянной спам на адрес "sales@supermail.com".
Также есть вероятность, что кто-то попробует открыть в браузере сам домен "supermail.com" (этот домен просто пример). То чтобы он вернул что-то осмысленное, я для него указал запись А, и запустил контейнер, который сам обновляет https сертификат и возвращает простую html строку.
Xeon / EPYC это обычные CPU, поэтому скорость генерации токенов будет слишком медленная, по несколько секунд на одно слово, тогда как Apple Silicon это несколько слов в секунду. Энергопотребление тоже не в пользу Intel / AMD.
Фактически, компьютеры от Apple - единственные на рынке с большим объемом RAM памяти, которая доступна не только CPU, но и GPU. В общем, это и есть unified memory и это идеально подходит для локального LLM inference: чаты, кодинг.
Вместо
git push --forceлучше всегда делатьgit push --force-with-lease. В чем разница? Допустим вы с Васей работаете над одной общей веткой и хотите исправить текст нового коммита, который вы только что отправили, но если Вася в это время отправил свой коммит, тоgit push --forceпросто молча выкинет его коммит из истории на сервере, потому что ваш репозиторий его не видит. Тогда какgit push --force-with-leaseзапрещает переписывание ветки, если там есть новые чужие коммиты. Я лично использую алиасgit pf.Сделать сразу грамотную архитектуру, писать только качественный код обычно нереально. Настоящие бизнес требования, которые приносят прибыль, находятся только после множества релизов.
Согласен, я сам разработчик, так всегда и происходит. Только я никого не оправдываю и не обвиняю. Замедление скорости доставки под грузом старой архитектуры и качества кода - это, к сожалению, нормально. Бизнес редко выбирает риск переписывания системы с нуля.
Это практически все случаи, когда кому-то платят деньги за написание кода. В бизнесе компания вынуждена зарабатывать деньги, а расходы на разработку ПО - это большая и серьезная статья расходов, которую она стремится минимизировать. Только корпорации могут себе позволить такие большие затраты.
Именно! Инженерам нужен длинный горизонт планирования, но в бизнесе ситуация постоянно меняется и планы тоже. Бизнесу нужны постоянные эксперименты с фичами, чтобы выжить, а инженер хочет неизменность функциональных требований. Это неизбежное фундаментальное противоречие.
Объяснение от обратного. Вот где реально необходимо писать качественный код? Когда цена необратимой ошибки очень высока: медицинское оборудование, ядро платежных систем, управление самолетом и т.д. И тут есть существенный минус: необходимо много времени на серьезный code review, глубокое тестирование перед релизом. В типичном корпоративном бизнесе все наоборот: скорость доставки на порядок важнее, чем отсутствие проблем в коде или архитектуре. Таким образом, это не является существенной проблемой самого бизнеса.
Все верно, это машинный код, а ассемблерный код - это низкоуровневый язык программирования, чей синтаксис зависит от конкретного железа.
Ссылка на эту задачу на литкоде. Только тут необходимо найти минимальную сумму.
https://leetcode.com/problems/triangle/description/
Доступные языки программирования:
Запуск на ARM со слабым железом, даже слабее Raspberry.
Какой абсолютный минимум объем RAM нужен для такого учебного проекта? И как насчёт сборки под ARM с запуском на QEMU и на физическом железе типа Raspberry?
narod.ru до сих пор работает? Аж олдскулы свело.
Честно говоря, эта юмористическая статья 2016 года не очень актуальна для Кремнивой долины образца марта 2023 года.
Всем спасибо за ссылки! Но сожалению, для меня они все большие и неудобные справочники, а не шпаргалки, как например вот эта по bash https://gist.github.com/lee2sman/423ef08fc2318969b3eaaf5d1e14e02e
Недавно мне надо было написать скрипт для docker alpine и я так и не смог нагуглить какой-нибудь нормальный cheat sheet для sh, так как в выдаче поиска был один только bash. Пришлось добавить
apk add --no-cache bash.Кто-нибудь может поделиться ссылкой на удобный справочник по sh?
У меня есть несколько доменных имён, которые указывают на 127.0.0.1. Используются для разработки, в частности чтобы иметь настоящий TLS сертификат для localhost, чтобы браузер сразу открывал веб приложение без лишних телодвижений.
Большинство людей считает, что если "сайт не открывается в браузере, то значит он сломан, включая и email".
У меня нет личного email сервера. Как-то пробовал, опыт отрицательный.
Я сделал немного по-другому. Купил домен у google domain, для примера пусть это будет "supermail.com". В его админке сделал бесплатный wildcard email forwarding на свой секретный email
*@supermail.com => secret@gmail.comТаким образом при регистрации где-либо я просто указываю абсолютно любой email на домене, например "uber@supermail.com", и без проблем получаю входящие письма на обычный gmail.
Отправить письмо как "uber@supermail.com" тоже несложно. Достаточно один раз подтвердить домен в каком-нибудь email delivery service и использовать его бесплатный план. В gmail есть настройка "send mail as" где можно создать любой исходящий адрес (alias), указав в моем случае "smtp.sendgrid.net", "apikey" и пароль.
Если на какой-то адрес начинает идти спам, то его можно полностью исключить, сделав для него google domain email forwarding на другой email, например мне приходил постоянной спам на адрес "sales@supermail.com".
Также есть вероятность, что кто-то попробует открыть в браузере сам домен "supermail.com" (этот домен просто пример). То чтобы он вернул что-то осмысленное, я для него указал запись А, и запустил контейнер, который сам обновляет https сертификат и возвращает простую html строку.