Т.е. мы избавляемся от принудительой типизации, но приходим к таким-же не менее принудительным тестам на 100% кодовой базы. А тесты как раз косвенно внутри содержат описания типов, чтобы падать в случае изменения структуры (я же не хочу чтобы мне по резултатам мержа или перепутанных параметров, в тест в поле для boolean флага прилетела строка, которая автоматом скастилась в сравнении в false, и из за этого отработало корректно до тех пор пока какой нибудь хитрец не введёт в текстовое поле true). А значит при изменении типа - всё равно придётся переписывать тест.
Как будто шило на мыло, только мыло хуже)
Кстати да, вспомнил все проекты сложнее двух файлов на языках с динамической типизацией, которые я видел - везде ~100% покрытия тестами, иначе с динамической типизацией особо не выжить)
Ну давайте к примеру из программирования - я на ревью буду ожидать утечки памяти, ошибки в условиях и граничных ситуациях. Но я никак не буду ожидать полное несоотвествие названий переменных и применения (а от нейронки я такое даже видел). Или разделения обработки непрерывной функции на отрезки.
Когда у вас int i = 0 это не итератор в цикле, а переменная определяющая видимость поля, int sum это итератор и т.д.
И ведь исходя из принципа оценки вероятности следования символов - выражения могут выглядеть очень логично, но на деле быть полной чушью.
Int D = b^2 — 4*a*c будет выглядеть совершенно логично, если все параметры передаются как аргументы, и не важно что b - это баланс, а c - скорость света, в точке вызова функции.
Вы исходите из тезиса - консистентный дизайн красивый и удобный, а не консистентный уродский и неудобный.
А такие тезисы нельзя принимать на веру ни в коем случае. (Например кажется очевидным что светофор с таймером снизит аварийность, но исследования говорят что он не только не делает лучше, а даже немного хуже, или что подземные переходы лучше наземных - но это тоже не так, или что широкие многополосные дороги снижают аварийность - а на деле все с точностью до наоборот).
Возможно вы видели исследования подтверждающие этот тезис?
Впрочем если на проекте 10 продуктовых команд делающих новые фичи - то это уже наверное тот масштаб когда и я соглашусь что ui-kit поможет в эфективности.
В городах больше 100к концепцию бесплатной парковки нужно убирать в принципе, это ошибка начальных лет автопрома, когда машину могли позволить себе лишь избранные. Общественное пространство города - общественное, это не место для частных авто. Также как когда хочешь разместить любую свою недвижимость - нужно арендовать землю, так и за машину - нужно арендовать парковку. Либо включить это в транспортный налог, как раз по тарифу 600р в час на 12 часов каждой день. Всего 28800 в месяц сверху, и можно и бесплатные парковки в городе.
Во первых, имел я личный контакт с человеком из администрации своего города - налоги, которые платят автомобилисты недостаточны даже для ямочного ремонта дорог (когда засыпают гравием и асфальт кладут сверху) - сейчас частное авто - сугубо субсидироемо дело, изначально подход был - "дороги всё равно нужны, а дальше уж кто может пусть пользуется пока пустые". Сейчас начали понимать, что это неправильно и делать автобусные полосы. Так то да, я не против, поднимаем транспортный налог в 50-200 раз, и строим хорошую инфраструктуру чисто для автомобилистов.
Но к сожалению и так не прокатит - т.к. есть ещё законы физики. Сша уже попытались построить автомобильную инфраструктуру для всех - итог - асфальтовые моря между которыми иногда стоят здания, и города, стоящие в пробках, эстакады, которые сейчас сноят потому что не вывозят обслуживание, и огромное количество других проблем с урбанистикой. Физику не обмануть - чтобы разместить авто на 10 этажку на кажого жителя, нужно занять ~20 её площадей, а если такие здания рядом и к ним транспортный поток в час пик - то дорога потребуется настолько широкая, что значительно увеличит размер улицы, если все улицы сделать такими, то город вырастет по площади - и теперь вы уже не дойдете до парка пешком, перед ним 5 8 полосных шоссе а не 5 перекретсков, и дорога на автобусе которая была 30 минут, станет 60, и вы на машине будете даже вне часа пик ехать дольше, чем до этого на от.
Про застройщиков, я бы с удовольствием посмотрел на такой эксперементальный проект в подмосковье - район, где застройщик обязан будет предоставить 2 парковочных места на каждую квартиру и выездную дорогу рассчиитную на этот пасажиро-поток - вероятно 12 полосное шоссе. И с каким диким трексом этот проект провалится в финансовый провал из за 4х-кратной стоимости жилья, и 8-кратных комунальных сборов.
Ну одно дело иметь с облаком комерческий договор, по которому они материально ответственны или хотя-бы репутационно, а другое - использовать хитрые хаки для нецелевого использования инструмента. В первом случае вы для владельцев облака товарищь и дорогой друг, а во втором паразит. Как бы риски на разных уровнях)
Удивительно как вы пишите комментарии не умея читать.
Я написал что для деплоя можно нанять подрядную компанию, а потом подробно описал какую часть работы снимает облако - и выделил что именно она обойдется дороже самого облака, до этого описал подробно в каких ситуациях.
Попробую обяьснить формулами.
При селфхосте расходы = админы для деплоя + админы выездные + железо
Пои облаке расходы = админы для деплоя + облако
Пункт "админы выездные" - стоит зачастую дороже облака - за 850 рублей в месяц вам даже smart по ssh не проверят, не то что приехать, всё продуть и обслужить или в срочном порядке поменять стучащий вентилятор или эктренно заменить дохлый диск. И да, я заменил админов на 2 графы расходов т.к. выезд стоит дороже
Про хетнцер - ну перечитайте мой первый комментарий из ветки в которой отвечаете - где я русским языком писал что "если у вас большие предсказуемые объемы работы и количество машин, то логично (использовать selfhosted кластер)" - желательно раза 4 перечитайте, а то что-то до вас туго как-то доходит.
Можно, но кому нужна система без драйверов и софта? А если включить поддержку линукса вместе с его ядром - это будет история "у нас есть 14 стандартов, давайте напишем единый который все заменит, у нас есть 15 стагдартов."
Если у вас своё железо - вам нужен админ в штате, чтобы за железом следил, мониторил состояния дисков, продувал вентиляторы, тестировал ибп, делал бекапы, короче выполнял регламентные работы. Либо нужен договор подряда, чтобы такой человек к вам выезжал. Либо перевесить это на какого то неспециалиста но ему все равно платить за доп работу, и нужно ещё чтобы человек согласился.
Если железо в облаке - всё это отдано на попечение оператору облака. Даже бекапы можно докупить, и они будут нести за них ответственность. (А в договоре ещё какой никакой sl может быть заложен если надо, и резервируемость линий и сети в датацентрах всё таки на совсем другом уровне)
И вот нанять админа в штат или выездного - скорее всего уже выйдет по цене сопоставимо с оплатой облака вместе с железом (на небольших объемах, про которые я и писал).
Ну и аргумент про масштабируемость остался - если после каких нибудь событий вы получите быстрый рост нагрузки, или она у вас сезонная/по датам - облоко можно докупить и в 10 раз сутки, после чего откатить через месяц - а свое оборудование только закупать месяц, а потом что - реализовывать на авито?
Ну на текущем этапе развития - железо для энтузиастов - 5090 x 2, и запускайте квантованные модели в свою удовольствие, а запускать полновесную модель - это уже как-то не про энтузиастов)
я не ожидаю что это будет стоить дешево, топовое железо дешево не стоит. Я ожидаю что это сделает доступным конфигурации с 256-512 общей памяти и какого-то вменяемого перфа в силу наличия видеоядра. Потому что сейчас для запуска инференса полных моделей нужно 8хA100 ценой по $10k каждая.
Я вижу у вас тут противоречие. Вы не ожидаете что топовое специализированное железо в экзотической конфируации будет стоить дешево, но ожидаете что будет стоить дешево доступно)) ну как бы оно доступно, вы же сами и написали что нужно 8хА100 и threadripper))
Скорее всего ускорители которые вы хотите кто-нибудь подвезет со временем, идея лежит на поверхности и потребности у рынка есть, просто нужно чутка подождать - сначала все тоже майнили на gpu а потом перешли на асики)
Не, долго пытался представить идеальный мир которые вы предлагаете. Встречное предложение - видеокарта должна собираться как отдельный пк - из компонентов - чип, плата, память, охлаждение, подсистема питания. Тогда верю что это могло бы иметь практическую ценность - купил новый чип и память, снял поменял, а охлад и плату старую оставил - правда рентабельность такого подхода уже вызывает сомнения - собрать монолитную модель может быть в цену дешевле на стоимость переиспользуемых компонентов, при условии добавления разъемов, интерфейсов, теплораспределительных крышек, сокетов и прочей лабуды. А 4 поколения в am4 - это последствия того, что вопервых там уже скорее не процессор а soc - где куча всего вынесена в сам кристалл, и того, что на рынке процессоров начался застой.
Распайка всей обвязки видеокарты на обычной материнской палте и все вот эти - два сокета - вот в это не верю. Это значит что сегмент пк без отдельного гпу - сразу становится закрытым для расширения (сейчас вполне реально купить пк с апу, а потом докопить и купить гпу - я знаю людей которые так делали), делает материнки сильно дороже, и вынуждает либо сильно переплатить, либо быть запертым в рамках потребления, tdp и параметров памяти. И добавляет вендорлок - если не произодйет чуда, и гпу не станут совместимы как по обвязке так и по сокету)
Ну и скорее всего эти свистоперделки ударят по производительности
Вообще генерация текстур казалось лежала на поверхности т.к. текстура почти всегда это просто паттерн, и сгенерированный он может выглядеть даже лучше, т.к. не будет явных повторов.
Но не приведёт ли это к тому, что каждый раз разворачиваясь на 360 картинка будет выглядеть иначе т.к. все текстуры перестроились иначе.
Хотя если они будут строиться относительно некоторого константного seed - то звучит как прорыв.
Как думаете вы - "захотел поменять видеокарту, заменил только 1 чип", как это было бы на самом деле - "захотел поменять на видеокарту поколение в плюс - нужно заменить материнку и процессор")) и веселье уровня - на материнке с 6 фазами питания карты выше XX60 не запускаются, а с 12 стоят в 2 раза дороже - и думай, переплатить под запас или недоплатить, но ограничить выбор)
Если у вас большие предсказуемые объёмы как работы так и машин - логично.
Но покупать и поддерживать целую машину которая будет загружена 5% времени, или нанимать админа ради двух пк - тут арендовать вполне будет дешевле. Взять тариф за 850 в месяц - чтобы закупить пк (даже бу) - выйдет 20 месяцев оплаты, чтобы обеспечить резерв компонентов - ещё 10 месяцев, ибп, место - еще 10 чтобы кто-то это настроил приехал, еще 20. Итого грубо - 5 лет оплаты облака надо вкинуть сразу. А там уже и железо спишут, и все заного надо.
Ну и облака это про мобильность и масштабируемость - увеличилась нагрузка в 10 раз на месяц - пока свою инрфу развернешь, он уже кончится, а с облака за сутки настроил, за сутки слил.
К сожалению зачастую гибдд просто игнорируют все. Снимал ряд машин запаркованных поверх велодорожки (дорожка сделана с примыканием к дороге), стоящих прямо под знаком на разметке. Несколько раз, по 5 - 10 машин. Просто присылают в ответ что я должен явиться в управление гибдд для подтверждения, причём в будний день, в рабочее время, и по каждому случаю в отдельный день. Да ещё и в управление, расположенное в 2 часах езды как от меня так и от места нарушений.
Хотя могли бы просто каждый день туда выезжать и стрчь деньги на массовых нарушениях.
Ладно, давайте пример прям из жизни из жизни, даже не придуманный. Два программиста работают над кодом - один меняет возвращаемый результат функции в одной ветке, а другой использует её в старом стиле в другой.
Оба делают мерж-реквест в корневую ветку. Конфликтов нет.
Только вот в случае со статической типизацией - изменение контракта не позволит вызывать метод и проект не соберется после добавления попытки вызова функции по старому.
А в случае динамической - здравствуй непредсказуемый результат т.к. непереданные параметры null - почему бы и нет.
Т.е. мы избавляемся от принудительой типизации, но приходим к таким-же не менее принудительным тестам на 100% кодовой базы. А тесты как раз косвенно внутри содержат описания типов, чтобы падать в случае изменения структуры (я же не хочу чтобы мне по резултатам мержа или перепутанных параметров, в тест в поле для boolean флага прилетела строка, которая автоматом скастилась в сравнении в false, и из за этого отработало корректно до тех пор пока какой нибудь хитрец не введёт в текстовое поле true). А значит при изменении типа - всё равно придётся переписывать тест.
Как будто шило на мыло, только мыло хуже)
Кстати да, вспомнил все проекты сложнее двух файлов на языках с динамической типизацией, которые я видел - везде ~100% покрытия тестами, иначе с динамической типизацией особо не выжить)
Ну давайте к примеру из программирования - я на ревью буду ожидать утечки памяти, ошибки в условиях и граничных ситуациях. Но я никак не буду ожидать полное несоотвествие названий переменных и применения (а от нейронки я такое даже видел). Или разделения обработки непрерывной функции на отрезки.
Когда у вас int i = 0 это не итератор в цикле, а переменная определяющая видимость поля, int sum это итератор и т.д.
И ведь исходя из принципа оценки вероятности следования символов - выражения могут выглядеть очень логично, но на деле быть полной чушью.
Int D = b^2 — 4*a*c будет выглядеть совершенно логично, если все параметры передаются как аргументы, и не важно что b - это баланс, а c - скорость света, в точке вызова функции.
Тут нужно ревью совсем совсем другого уровня.
Вы исходите из тезиса - консистентный дизайн красивый и удобный, а не консистентный уродский и неудобный.
А такие тезисы нельзя принимать на веру ни в коем случае. (Например кажется очевидным что светофор с таймером снизит аварийность, но исследования говорят что он не только не делает лучше, а даже немного хуже, или что подземные переходы лучше наземных - но это тоже не так, или что широкие многополосные дороги снижают аварийность - а на деле все с точностью до наоборот).
Возможно вы видели исследования подтверждающие этот тезис?
Впрочем если на проекте 10 продуктовых команд делающих новые фичи - то это уже наверное тот масштаб когда и я соглашусь что ui-kit поможет в эфективности.
В городах больше 100к концепцию бесплатной парковки нужно убирать в принципе, это ошибка начальных лет автопрома, когда машину могли позволить себе лишь избранные. Общественное пространство города - общественное, это не место для частных авто. Также как когда хочешь разместить любую свою недвижимость - нужно арендовать землю, так и за машину - нужно арендовать парковку. Либо включить это в транспортный налог, как раз по тарифу 600р в час на 12 часов каждой день. Всего 28800 в месяц сверху, и можно и бесплатные парковки в городе.
Во первых, имел я личный контакт с человеком из администрации своего города - налоги, которые платят автомобилисты недостаточны даже для ямочного ремонта дорог (когда засыпают гравием и асфальт кладут сверху) - сейчас частное авто - сугубо субсидироемо дело, изначально подход был - "дороги всё равно нужны, а дальше уж кто может пусть пользуется пока пустые". Сейчас начали понимать, что это неправильно и делать автобусные полосы. Так то да, я не против, поднимаем транспортный налог в 50-200 раз, и строим хорошую инфраструктуру чисто для автомобилистов.
Но к сожалению и так не прокатит - т.к. есть ещё законы физики. Сша уже попытались построить автомобильную инфраструктуру для всех - итог - асфальтовые моря между которыми иногда стоят здания, и города, стоящие в пробках, эстакады, которые сейчас сноят потому что не вывозят обслуживание, и огромное количество других проблем с урбанистикой. Физику не обмануть - чтобы разместить авто на 10 этажку на кажого жителя, нужно занять ~20 её площадей, а если такие здания рядом и к ним транспортный поток в час пик - то дорога потребуется настолько широкая, что значительно увеличит размер улицы, если все улицы сделать такими, то город вырастет по площади - и теперь вы уже не дойдете до парка пешком, перед ним 5 8 полосных шоссе а не 5 перекретсков, и дорога на автобусе которая была 30 минут, станет 60, и вы на машине будете даже вне часа пик ехать дольше, чем до этого на от.
Про застройщиков, я бы с удовольствием посмотрел на такой эксперементальный проект в подмосковье - район, где застройщик обязан будет предоставить 2 парковочных места на каждую квартиру и выездную дорогу рассчиитную на этот пасажиро-поток - вероятно 12 полосное шоссе. И с каким диким трексом этот проект провалится в финансовый провал из за 4х-кратной стоимости жилья, и 8-кратных комунальных сборов.
Ну одно дело иметь с облаком комерческий договор, по которому они материально ответственны или хотя-бы репутационно, а другое - использовать хитрые хаки для нецелевого использования инструмента. В первом случае вы для владельцев облака товарищь и дорогой друг, а во втором паразит. Как бы риски на разных уровнях)
Удивительно как вы пишите комментарии не умея читать.
Я написал что для деплоя можно нанять подрядную компанию, а потом подробно описал какую часть работы снимает облако - и выделил что именно она обойдется дороже самого облака, до этого описал подробно в каких ситуациях.
Попробую обяьснить формулами.
При селфхосте расходы = админы для деплоя + админы выездные + железо
Пои облаке расходы = админы для деплоя + облако
Пункт "админы выездные" - стоит зачастую дороже облака - за 850 рублей в месяц вам даже smart по ssh не проверят, не то что приехать, всё продуть и обслужить или в срочном порядке поменять стучащий вентилятор или эктренно заменить дохлый диск. И да, я заменил админов на 2 графы расходов т.к. выезд стоит дороже
Про хетнцер - ну перечитайте мой первый комментарий из ветки в которой отвечаете - где я русским языком писал что "если у вас большие предсказуемые объемы работы и количество машин, то логично (использовать selfhosted кластер)" - желательно раза 4 перечитайте, а то что-то до вас туго как-то доходит.
Можно, но кому нужна система без драйверов и софта? А если включить поддержку линукса вместе с его ядром - это будет история "у нас есть 14 стандартов, давайте напишем единый который все заменит, у нас есть 15 стагдартов."
Если у вас своё железо - вам нужен админ в штате, чтобы за железом следил, мониторил состояния дисков, продувал вентиляторы, тестировал ибп, делал бекапы, короче выполнял регламентные работы. Либо нужен договор подряда, чтобы такой человек к вам выезжал. Либо перевесить это на какого то неспециалиста но ему все равно платить за доп работу, и нужно ещё чтобы человек согласился.
Если железо в облаке - всё это отдано на попечение оператору облака. Даже бекапы можно докупить, и они будут нести за них ответственность. (А в договоре ещё какой никакой sl может быть заложен если надо, и резервируемость линий и сети в датацентрах всё таки на совсем другом уровне)
И вот нанять админа в штат или выездного - скорее всего уже выйдет по цене сопоставимо с оплатой облака вместе с железом (на небольших объемах, про которые я и писал).
Ну и аргумент про масштабируемость остался - если после каких нибудь событий вы получите быстрый рост нагрузки, или она у вас сезонная/по датам - облоко можно докупить и в 10 раз сутки, после чего откатить через месяц - а свое оборудование только закупать месяц, а потом что - реализовывать на авито?
Ну на текущем этапе развития - железо для энтузиастов - 5090 x 2, и запускайте квантованные модели в свою удовольствие, а запускать полновесную модель - это уже как-то не про энтузиастов)
Я вижу у вас тут противоречие. Вы не ожидаете что топовое специализированное железо в экзотической конфируации будет стоить дешево, но ожидаете что будет стоить
дешеводоступно)) ну как бы оно доступно, вы же сами и написали что нужно 8хА100 и threadripper))Скорее всего ускорители которые вы хотите кто-нибудь подвезет со временем, идея лежит на поверхности и потребности у рынка есть, просто нужно чутка подождать - сначала все тоже майнили на gpu а потом перешли на асики)
Не, долго пытался представить идеальный мир которые вы предлагаете. Встречное предложение - видеокарта должна собираться как отдельный пк - из компонентов - чип, плата, память, охлаждение, подсистема питания.
Тогда верю что это могло бы иметь практическую ценность - купил новый чип и память, снял поменял, а охлад и плату старую оставил - правда рентабельность такого подхода уже вызывает сомнения - собрать монолитную модель может быть в цену дешевле на стоимость переиспользуемых компонентов, при условии добавления разъемов, интерфейсов, теплораспределительных крышек, сокетов и прочей лабуды. А 4 поколения в am4 - это последствия того, что вопервых там уже скорее не процессор а soc - где куча всего вынесена в сам кристалл, и того, что на рынке процессоров начался застой.
Распайка всей обвязки видеокарты на обычной материнской палте и все вот эти - два сокета - вот в это не верю. Это значит что сегмент пк без отдельного гпу - сразу становится закрытым для расширения (сейчас вполне реально купить пк с апу, а потом докопить и купить гпу - я знаю людей которые так делали), делает материнки сильно дороже, и вынуждает либо сильно переплатить, либо быть запертым в рамках потребления, tdp и параметров памяти. И добавляет вендорлок - если не произодйет чуда, и гпу не станут совместимы как по обвязке так и по сокету)
Ну и скорее всего эти свистоперделки ударят по производительности
Вообще генерация текстур казалось лежала на поверхности т.к. текстура почти всегда это просто паттерн, и сгенерированный он может выглядеть даже лучше, т.к. не будет явных повторов.
Но не приведёт ли это к тому, что каждый раз разворачиваясь на 360 картинка будет выглядеть иначе т.к. все текстуры перестроились иначе.
Хотя если они будут строиться относительно некоторого константного seed - то звучит как прорыв.
И когда что-то одно захотел заменить - менять нужно все потому что сокеты устарели)
Как думаете вы - "захотел поменять видеокарту, заменил только 1 чип", как это было бы на самом деле - "захотел поменять на видеокарту поколение в плюс - нужно заменить материнку и процессор")) и веселье уровня - на материнке с 6 фазами питания карты выше XX60 не запускаются, а с 12 стоят в 2 раза дороже - и думай, переплатить под запас или недоплатить, но ограничить выбор)
Если у вас большие предсказуемые объёмы как работы так и машин - логично.
Но покупать и поддерживать целую машину которая будет загружена 5% времени, или нанимать админа ради двух пк - тут арендовать вполне будет дешевле. Взять тариф за 850 в месяц - чтобы закупить пк (даже бу) - выйдет 20 месяцев оплаты, чтобы обеспечить резерв компонентов - ещё 10 месяцев, ибп, место - еще 10 чтобы кто-то это настроил приехал, еще 20. Итого грубо - 5 лет оплаты облака надо вкинуть сразу. А там уже и железо спишут, и все заного надо.
Ну и облака это про мобильность и масштабируемость - увеличилась нагрузка в 10 раз на месяц - пока свою инрфу развернешь, он уже кончится, а с облака за сутки настроил, за сутки слил.
Самая большая проблема данного подхода - вероятность остаться полностью без данных в один момент
К сожалению зачастую гибдд просто игнорируют все. Снимал ряд машин запаркованных поверх велодорожки (дорожка сделана с примыканием к дороге), стоящих прямо под знаком на разметке. Несколько раз, по 5 - 10 машин. Просто присылают в ответ что я должен явиться в управление гибдд для подтверждения, причём в будний день, в рабочее время, и по каждому случаю в отдельный день. Да ещё и в управление, расположенное в 2 часах езды как от меня так и от места нарушений.
Хотя могли бы просто каждый день туда выезжать и стрчь деньги на массовых нарушениях.
Это сделано намеренно, чтобы вы поехали по выделенке на ОТ, а не перегружали инфраструктуру.
Ладно, давайте пример прям из жизни из жизни, даже не придуманный.
Два программиста работают над кодом - один меняет возвращаемый результат функции в одной ветке, а другой использует её в старом стиле в другой.
Оба делают мерж-реквест в корневую ветку. Конфликтов нет.
Только вот в случае со статической типизацией - изменение контракта не позволит вызывать метод и проект не соберется после добавления попытки вызова функции по старому.
А в случае динамической - здравствуй непредсказуемый результат т.к. непереданные параметры null - почему бы и нет.
И таких примеров можно придумать много.