Так вот почему при заборе крови все время спрашивают, будет ли плохо, не нужно ли подстраховаться. Даже не подозревал что от вида крови может быть такая реакция.
Менеджер не лидер, он вообще по отношению к команде внешняя сущность. И, как уже тут сказали, команда его не примет как одного из своих, он не погружен в реалии кода. Менеджер это управленец, он владеет конкретным продуктом, ведет учет, управляет потоком задач на высоком уровне, следит за бюджетом и учитывает интересы продукта. Команда это исполнительный блок, группа специалистов разной квалификации и специализации, она разбирает поток задач и выполняет эти задачи наиболее эффективным способом, с учетом доступных ресурсов и компетенций. Слаженная команда может принадлежать нескольким проектам, а в случае разногласий иногда и фирму покидает в полном составе, такие случаи история уже знает. Тимлид тут это просто старший опытный разработчик, знакомый со спецификой кода, с бизнес-процессами, с реалиями корпоративных игр вышестоящих товарищей. Лид способен быть интерфейсом между командой и бизнесом, это наиболее грамотный, и в техническом плане, и в бизнес-плане, человек, который понимает о чем говорят вышестоящие товарищи, понимает их реальные потребности, и реальные ограничения текущего кода, понимает проблематику сверху и снизу. Лид способен перевести технические подробности на язык бизнеса, и бизнес-потребности на язык технарей. Его задача быть клеем, и внутри команды, и внутри бизнеса, оптимизировать процессы, пресекать тупняки, находить короткие пути решения тех или иных проблем, не учитывая никакие зоны ответственности, на чем спотыкаются обычные разработчики. Его задача быть крайним в команде, замыкать все внутренние вопросы и проблемы на себе, не допускать их утечки вовне, не допускать нарушения зон ответственности. Именно его будут нагружать разработчики всякими проблемами и непонятками, и он их разрешает за считанные минуты, тем самым избегая серьезных простоев на ровном месте, потому что без лида в таких случаях начинается игра в "горячую картошку", никто на себя ответственность не берет, и простейший технический вопрос утекает наверх, покидает зону ответственности технарей, и летает по всяким менеджерам и управленцам, которые не понимают что от них хотят и причем тут они вообще, и летать он там может неделями, что выглядит просто дико. Также задача лида - тактические, оперативные решения, внутри его сферы ответственности: многие вопросы или проблемы можно решить внутри команды, без привлечения внешних , и тем самым сократить время на всякую бюрократию, увеличить эффективность процессов - время ответа человека за пределами команды может достигать недели-двух, а пинг до лида обычно менее часа. И его задача быть ориентиром, вдохновлять молодых - как ни крути, но внутри команды самый большой авторитет именно у лида, новички к лиду обычно относятся особенно трепетно, в их глазах это чуть ли не человек-легенда, на его авторитет работает и огромный опыт, и роль, и тот факт что с ним считается бизнес и он постоянно пропадает на совещаниях с большими людьми, ну и личный фактор конечно же, рано или поздно лид окажет помощь каждому из команды, решит его проблему.
В целом разработка - процесс творческий, так что на конкретные сроки он не ложится, все зависит, если угодно, от музы.
Конечно всегда много шаблонной и более-менее предсказуемой рутины, но бывают и творческие задачи, или задачи на удачу, за которые никто не скажет как ее решить, и возможно ли ее решить в принципе.
Бывает на задачу выделено 40 часов бюджета, и первые 30 уходят на то, чтобы понять как к ней подступиться - в эти 30 часов могут быть перебрано несколько решений, от которых придется отказаться на той или иной стадии, кода вообще может не быть, потому что тупо крутишь идеи в голове и обсасываешь их, пока не проявится смутное чувство близости победы, "хм, а ведь если сделать вот так, то быть может все получится как надо, или хотя бы будем на шаг ближе к решению". Это как шахматная партия. И победить можно не всегда, но очень хочется.
Над одной из таких проблем пришлось несколько суток размышлять, делать предположения, опровергать их, отвергать идеи и решения, в итоге озарение пришло за полсуток до срока, который выделил на поиск решения или отказ. Смутная идея того, как раскусить проблему, пришла под струями душа, вечером, "ниоткуда" - мысль просто всплыла откуда-то из глубин. Думаю так мозг доносит результаты своей фоновой активности: частенько бывает, что решения приходят сами собой, если заранее загрузить в себя проблему, а потом просто заняться чем-то другим, через некоторое время решение просто начнет крутиться в голове, хотя сознательно им никто не занимался. Идея была смутной, и нестандартной, в эту сторону еще не думал ни я, ни мои предшественники, и чувствовалось что проработка этой идеи может либо приблизить к решению, либо щать само решение, так что с этой идеей было решено переспать, чтобы мозг дополнительно ее покрутил в фоне, как он это умеет. А на утро уже было целых два варианта на ее основе: полноценное решение, и частичное. Второе - чтобы облегчить жизнь бизнесу, на случай, если проблема все же окажется нерешаемой. Как итог все выгорело, а мне в копилку упал новый ценный инструмент для решения такого класса задач. Как оказалось, проблема эта была ежегодная, и никто даже не рассчитывал что она решаема: ежегодно, несколько лет подряд, бизнес кидался ей в команды сеньоров, которые каждый раз разводили руками, потому что после первичного анализа выяснялось, что проблема фундаментальна, и классические решения с ней не работают. Я же просто прошел на шаг дальше в анализе, разобрался какой именно фактор обламывает классическое решение. А также решил попробовать исключить этот фактор из проблемы: просто отсек его, "вынес за скобки". В результате проблема схлопнулась до тривиальной. Тут то и стало понятно, что таким же образом можно решать и другие "нерешаемые" классическим образом проблемы. Идея простая, но разработчиков никто не учит, что можно просто сделать шаг в сторону и изменить саму проблему.
Еще может быть такой кейс: лучше плохо, но сейчас, чем хорошо, но уже, быть может, никогда. В ситуациях, где важно время, решения могут быть менее аккуратными, важнее сам факт выполнения задачи, а не идеальность решения.
Если нужно выполнить код на другой машине, есть RPC.
Если нужна внешняя память или кеш, есть миллион специализированных сервисов, типа redis.
Если это попытка сэкономить ресурсы, то лучше просто обновить железо: на современном железе можно не думать о памяти и потоках. Бытовое железо позволяет крутить 32 потока, серверное - больше 256 потоков. Память измеряется десятками или тысячами гигов соответственно. И все это локально, без всяких игр с сетью, с минимальными задержками. Основная сложность на таком железе это максимально его нагрузить, что сделать совсем не просто.
А любая попытка экономить ресурсы таким сложным образом на слабом железе, это просто гарантированные лаги и задержки: физически не существует способа вовремя предсказать, когда потребуется подогреть код, который ради экономии ресурсов охладили. Накопление статистики по коду от лагов не избавляет - накопление статистики снижает процент промахов, снижает количество лагов, но лишь на фоне случая, когда лаги идут при каждом вызове функционала, на котором сэкономили, а в остальном это игра вслепую с минимальной эффективностью, человек с задачами оптимизации справляется гораздо эффективнее статистики. И любые подобные игры в оптимизацию в ситуации, когда ресурсов и так не хватает, это просто дополнительные накладные расходы: накопление статистики, логика оптимизатора и трансфер данных - это все тоже требует ресурсов.
Если действительно есть данные, которые нужно хранить постоянно, но которые достаточно быстро остывают, проще их просто вытеснять в какой-нибудь кеш по таймауту неактивности, это гораздо экономнее по ресурсам и проще по логике, промахи это не уберет, но также их снизит примерно до уровня реализации со сбором статистики. А уж для кешей готовых реализаций много: библиотечных, внешних, удаленных - каких угодно, это стандартный кирпичик современного софта.
А вообще на практике успешно работают следующие способы оптимизации:
грамотно расставленные по коду кеши: если что-то есть в кеше, это не требуется повторно вычислять. Если что-то нельзя кешировать, это можно распилить на статическую и динамическую часть, и кешировать статическую. Если динамическая часть имеет конечный и не очень большой набор вариантов - это тоже статическая часть
размен циклов на память. Например замена вычислений на выборку по смещению в предварительно посчитанной табличке или карте - этот лайфхах еще из докомпьютерной эпохи
оптимизация под железо. Горячую часть кода упрощают и уменьшают, чтобы подольше не выходить за пределы аппаратных кешей. Данные читают и размещают последовательно, чтобы работали механизмы аппаратной предзагрузки на всех уровнях и аппаратные кеши не опустошались. Заранее прогревают программные кеши запросом или вычиткой данных, до того как запустится горячая часть кода. Также на железо хорошо ложится функциональный подход, коллекции и потоки: оно однотипно, последовательно, и содержит меньше условных операторов, чем традиционный код
размен циклов на время. Например сжатие больших кешей или отправляемых данных, если они хорошо жмутся: это дает дополнительную нагрузку на cpu, но ускоряет ввод/вывод в 5-10 раз. Жмут современные cpu быстро, хватает на большинство каналов ввода/вывода. Если cpu систематически недогружен и много текстового ввода/вывода, появляется возможность использовать такой размен
Просто комбинируя эти принципы можно ускорить код на 2-3 порядка практически на ровном месте
Вот и у меня странное антибликовое покрытие. Очень непривычно после матового пластика. Поверхность глянцевая, сама панель стеклянная, ожидается сильный зеркальный эффект, но на зеркало это не похоже, отражения есть, они четкие, но очень темные, на практике их не видно, они не мешают, и уловить их можно только на черных участках, и сами блики необычные, не слепят, и красиво рассыпаются на фрагменты.
Похоже на описание "ночного режима". Есть из коробки во многих смартфонах, в win11 и KDE. По дефолту настраивается на время активности "от заката до рассвета". Как раз уводит картинки в янтарные оттенки.
Если позитрон живет в антивремени и существует в нашей вселенной, и известно что из квантовой пены могут возникать частицы и античастицы, то логично предположить что вселенная и антивселенная, время и антивремя, существуют в одном и том же пространстве, и квантовая пена как раз является проявлением этого. Далее логично предположить, что если вселенная и антивселенная находятся в одном пространстве, и существует такое явление как квантовая пена, свидетельствующее о том, что вселенная и антивселенная в каких-то местах в какие-то особые моменты могут взаимодействовать друг с другом, обмениваться материей в небольших точках, в которых нарушается равновесие, то, уже чисто по теории вероятности и закона больших чисел, где-то в пространстве просто обязаны существовать огромные регионы, где это самое равновесие нарушено, и вместо квантовой пены там должны наблюдаться квантовые штормы, с огромными объемами чужеродной материи и другими спецэффектами, такими например как источники антигравитации - если антигравитация хоть как-то может быть связана с антивселенной, то она будет именно там, в этих регионах.
Есть коврики специальные, котейки стряхивают на них почти все. Но не липнет минеральный наполнитель, который "без запаха", он всегда сухой, потому что быстро все впитывает и цементируется, а силикагель наверное липнет в любом случае, сомневаюсь что он так хорошо и быстро впитывает, как минеральный.
Можно той же самой сетке дать задание оценить свой ответ и доработать его. И дорабатывать пока оценка не станет удовлетворительной. Закольцовывать можно как внешним кодом, так и заставить саму сетку общаться с собой - такие промты тоже есть. Но если это на уровне промтов делать, побочка в том, что весь внутренний диалог сетки вываливается в чатик, так что лучше это прятать. Но наблюдать этот диалог конечно забавно - этакое раздвоение личности, исполнитель и ревизор в одном лице.
Верно. Нужно уметь делегировать, грамотно использовать имеющиеся ресурсы в виде доступных специалистов, тогда достаточно будет лишь выстроить процессы, с учетом реалий на местах, и следить чтобы эти процессы не развалились. И останется лишь роль координатора. Но на практике задача эта не простая, люди не любят изменений, и активно будут противодействовать попыткам выстроить процессы. Нужны крепкие нервы, упертость, навыки убеждения и ведения переговоров. Толковых руководителей немного, но у кого получается, те идут далеко и ярко.
В линукс есть нативный llama.cpp и его производные: запускается сервер с нейронкой, и клиенты к нему шлют запросы. Клиенты есть консольные (сам llama.cpp такой предоставляет), браузерные, есть встроенные в популярные IDE плагинами. Нейронку можно выбрать самому из предустановленного списка или скачать любую другую - они все в стандартных форматах в интернете выложены. Все это работает локально, и доступно на любой современной видеокарте. Nvidia или amd - без разницы, сейчас оба вендора предоставляют равноценную поддержку ускорения нейронок.
Навигатор человека не заменит. Только недавно наблюдал такую картину: навигатор перед перекрестком показывает поворот на спуск, и это ожидаемый вариант, а через минуту навигатор потерялся и начал показывать окраины города, таксист в это время поехал прямо, а не на поворот на спуск, чего я не ожидал, но через 5 минут стало ясно что таксист просто хорошо знает этот район, и просто оптимизировал маршрут через мелкие улочки, а навигатор в себя пришел только уже перед остановкой. Так что тут сразу две проблемы навигатора проявились: он ненадежен и в любой момент может отказать, и он знает дорогу хуже опытного человека.
Нейросети в текущем виде не в состоянии не врать. Это их суть работы: синтез по матрице вероятностей, которую тренируют выдавать наиболее правдоподобные ответы. Но не наиболее правдивые - такой опции нет. Может быть нейросети каких-нибудь других архитектур, принципиально отличных от архитектуры языковых моделей, будут способны хотя бы в подобие мыслительного процесса и минимально осознанных ответов. Текущие же архитектуры на такое принципиально не способны, поэтому их удел пока - всякие развлечения, все что не требует точности и фактов.
Самый правильный вариант не всегда работает. Даже на крупных сайтах не всегда есть какие-либо удобные форматы использования, или же есть только устаревшие проблемные варианты. Разработчик может не разбираться в тонкостях конкретного linux, а их много. У него может просто отсутствовать мотивация поддерживать все это - чего уж говорить, таким страдают даже техногиганты с миллиардными бюджетами.
Так что правильнее, если пакеты под конкретный дистрибутив все же будет компилировать и собирать тот, кто работает с конкретным дистрибутивом.
На практике лучший опыт получается с софтом, исходники которого публично доступны в каком-нибудь репозитории, без регистрации и смс. Для такого софта доступен самый большой набор вариантов: от собственноручной сборки под свою ОС и машину, до прозрачного встраивания софта в любую пакетную базу: любой заинтересованный человек со стороны может подключить чужой публичный репозиторий к своей системе сборки пакетов, без какой-либо бюрократии и ограничений.
Такой софт доступен практически во всех пакетных базах, даже самых экзотических, и в каждой собирается по-своему: где-то статически, где-то под конкретные системные библиотеки доступные в конкретном релизе дистрбутива.
Сейчас много всяких dns со встроенными фильтрами от рекламы и трекинга, достаточно один раз озаботиться и прописать в роутер, и даже не замечаешь что реклама существует. Настолько не замечаешь, что перестаешь понимать на что жалуются люди, забываешь как выглядит интернет без фильтров
Что там с фильмом непонятно, но в играх с HDR разница видна: на SDR все хорошо, но нужно выбирать, или яркие источники света и вместо теней черное пятно, или пересвет но зато видно что в тенях делается, а с HDR доступны одновременно и яркие источники света и детали в тенях - динамический диапазон явно больше, можно заглядывать с улицы в пещеру или тоннель и видеть там что-то. Но некоторые игры это портят эффектом адаптации зрения: на ярких сценах через короткое время затемняют тени, а в темных сценах наоборот завышают яркость неба в окнах.
Также HDR сильно поднимает яркость точечных источников: например яркая-яркая луна ночью на фоне полутьмы окружения. На OLED это неплохо выглядит - там в таких сценах яркости могут быть огромные, хотя на всю панель такую яркость они выдать не способны, перегреваются мгновенно, полная яркость доступна только точечно.
Для 3D сейчас целый класс устройств появился - очки виртуальной реальности и сопутствующие аксессуары
А вот с HDR до сих пор не определились - нарожали 100500 стандартов, и нативно их никто не поддерживает. Что в windows, что в linux HDR прикрутили костылями. Много проблем на ровном месте с этим HDR. Хотя картинка конечно лучше - больше деталей в тенях. Но сейчас и моники научились тени высветлять из коробки, всякие игровые режимы на это и заточены. Хотелось бы чтобы стандарты HDR устаканились и все работало из коробки, как это сейчас с SDR происходит: кабель подключил и не заморачиваешься более.
Так вот почему при заборе крови все время спрашивают, будет ли плохо, не нужно ли подстраховаться. Даже не подозревал что от вида крови может быть такая реакция.
Менеджер не лидер, он вообще по отношению к команде внешняя сущность. И, как уже тут сказали, команда его не примет как одного из своих, он не погружен в реалии кода. Менеджер это управленец, он владеет конкретным продуктом, ведет учет, управляет потоком задач на высоком уровне, следит за бюджетом и учитывает интересы продукта. Команда это исполнительный блок, группа специалистов разной квалификации и специализации, она разбирает поток задач и выполняет эти задачи наиболее эффективным способом, с учетом доступных ресурсов и компетенций. Слаженная команда может принадлежать нескольким проектам, а в случае разногласий иногда и фирму покидает в полном составе, такие случаи история уже знает. Тимлид тут это просто старший опытный разработчик, знакомый со спецификой кода, с бизнес-процессами, с реалиями корпоративных игр вышестоящих товарищей. Лид способен быть интерфейсом между командой и бизнесом, это наиболее грамотный, и в техническом плане, и в бизнес-плане, человек, который понимает о чем говорят вышестоящие товарищи, понимает их реальные потребности, и реальные ограничения текущего кода, понимает проблематику сверху и снизу. Лид способен перевести технические подробности на язык бизнеса, и бизнес-потребности на язык технарей. Его задача быть клеем, и внутри команды, и внутри бизнеса, оптимизировать процессы, пресекать тупняки, находить короткие пути решения тех или иных проблем, не учитывая никакие зоны ответственности, на чем спотыкаются обычные разработчики. Его задача быть крайним в команде, замыкать все внутренние вопросы и проблемы на себе, не допускать их утечки вовне, не допускать нарушения зон ответственности. Именно его будут нагружать разработчики всякими проблемами и непонятками, и он их разрешает за считанные минуты, тем самым избегая серьезных простоев на ровном месте, потому что без лида в таких случаях начинается игра в "горячую картошку", никто на себя ответственность не берет, и простейший технический вопрос утекает наверх, покидает зону ответственности технарей, и летает по всяким менеджерам и управленцам, которые не понимают что от них хотят и причем тут они вообще, и летать он там может неделями, что выглядит просто дико. Также задача лида - тактические, оперативные решения, внутри его сферы ответственности: многие вопросы или проблемы можно решить внутри команды, без привлечения внешних , и тем самым сократить время на всякую бюрократию, увеличить эффективность процессов - время ответа человека за пределами команды может достигать недели-двух, а пинг до лида обычно менее часа. И его задача быть ориентиром, вдохновлять молодых - как ни крути, но внутри команды самый большой авторитет именно у лида, новички к лиду обычно относятся особенно трепетно, в их глазах это чуть ли не человек-легенда, на его авторитет работает и огромный опыт, и роль, и тот факт что с ним считается бизнес и он постоянно пропадает на совещаниях с большими людьми, ну и личный фактор конечно же, рано или поздно лид окажет помощь каждому из команды, решит его проблему.
Все это знакомо.
В целом разработка - процесс творческий, так что на конкретные сроки он не ложится, все зависит, если угодно, от музы.
Конечно всегда много шаблонной и более-менее предсказуемой рутины, но бывают и творческие задачи, или задачи на удачу, за которые никто не скажет как ее решить, и возможно ли ее решить в принципе.
Бывает на задачу выделено 40 часов бюджета, и первые 30 уходят на то, чтобы понять как к ней подступиться - в эти 30 часов могут быть перебрано несколько решений, от которых придется отказаться на той или иной стадии, кода вообще может не быть, потому что тупо крутишь идеи в голове и обсасываешь их, пока не проявится смутное чувство близости победы, "хм, а ведь если сделать вот так, то быть может все получится как надо, или хотя бы будем на шаг ближе к решению". Это как шахматная партия. И победить можно не всегда, но очень хочется.
Над одной из таких проблем пришлось несколько суток размышлять, делать предположения, опровергать их, отвергать идеи и решения, в итоге озарение пришло за полсуток до срока, который выделил на поиск решения или отказ. Смутная идея того, как раскусить проблему, пришла под струями душа, вечером, "ниоткуда" - мысль просто всплыла откуда-то из глубин. Думаю так мозг доносит результаты своей фоновой активности: частенько бывает, что решения приходят сами собой, если заранее загрузить в себя проблему, а потом просто заняться чем-то другим, через некоторое время решение просто начнет крутиться в голове, хотя сознательно им никто не занимался. Идея была смутной, и нестандартной, в эту сторону еще не думал ни я, ни мои предшественники, и чувствовалось что проработка этой идеи может либо приблизить к решению, либо щать само решение, так что с этой идеей было решено переспать, чтобы мозг дополнительно ее покрутил в фоне, как он это умеет. А на утро уже было целых два варианта на ее основе: полноценное решение, и частичное. Второе - чтобы облегчить жизнь бизнесу, на случай, если проблема все же окажется нерешаемой. Как итог все выгорело, а мне в копилку упал новый ценный инструмент для решения такого класса задач. Как оказалось, проблема эта была ежегодная, и никто даже не рассчитывал что она решаема: ежегодно, несколько лет подряд, бизнес кидался ей в команды сеньоров, которые каждый раз разводили руками, потому что после первичного анализа выяснялось, что проблема фундаментальна, и классические решения с ней не работают. Я же просто прошел на шаг дальше в анализе, разобрался какой именно фактор обламывает классическое решение. А также решил попробовать исключить этот фактор из проблемы: просто отсек его, "вынес за скобки". В результате проблема схлопнулась до тривиальной. Тут то и стало понятно, что таким же образом можно решать и другие "нерешаемые" классическим образом проблемы. Идея простая, но разработчиков никто не учит, что можно просто сделать шаг в сторону и изменить саму проблему.
Еще может быть такой кейс: лучше плохо, но сейчас, чем хорошо, но уже, быть может, никогда. В ситуациях, где важно время, решения могут быть менее аккуратными, важнее сам факт выполнения задачи, а не идеальность решения.
Выглядит как изобретение велосипеда.
Если нужно выполнить код на другой машине, есть RPC.
Если нужна внешняя память или кеш, есть миллион специализированных сервисов, типа redis.
Если это попытка сэкономить ресурсы, то лучше просто обновить железо: на современном железе можно не думать о памяти и потоках. Бытовое железо позволяет крутить 32 потока, серверное - больше 256 потоков. Память измеряется десятками или тысячами гигов соответственно. И все это локально, без всяких игр с сетью, с минимальными задержками. Основная сложность на таком железе это максимально его нагрузить, что сделать совсем не просто.
А любая попытка экономить ресурсы таким сложным образом на слабом железе, это просто гарантированные лаги и задержки: физически не существует способа вовремя предсказать, когда потребуется подогреть код, который ради экономии ресурсов охладили. Накопление статистики по коду от лагов не избавляет - накопление статистики снижает процент промахов, снижает количество лагов, но лишь на фоне случая, когда лаги идут при каждом вызове функционала, на котором сэкономили, а в остальном это игра вслепую с минимальной эффективностью, человек с задачами оптимизации справляется гораздо эффективнее статистики. И любые подобные игры в оптимизацию в ситуации, когда ресурсов и так не хватает, это просто дополнительные накладные расходы: накопление статистики, логика оптимизатора и трансфер данных - это все тоже требует ресурсов.
Если действительно есть данные, которые нужно хранить постоянно, но которые достаточно быстро остывают, проще их просто вытеснять в какой-нибудь кеш по таймауту неактивности, это гораздо экономнее по ресурсам и проще по логике, промахи это не уберет, но также их снизит примерно до уровня реализации со сбором статистики. А уж для кешей готовых реализаций много: библиотечных, внешних, удаленных - каких угодно, это стандартный кирпичик современного софта.
А вообще на практике успешно работают следующие способы оптимизации:
грамотно расставленные по коду кеши: если что-то есть в кеше, это не требуется повторно вычислять. Если что-то нельзя кешировать, это можно распилить на статическую и динамическую часть, и кешировать статическую. Если динамическая часть имеет конечный и не очень большой набор вариантов - это тоже статическая часть
размен циклов на память. Например замена вычислений на выборку по смещению в предварительно посчитанной табличке или карте - этот лайфхах еще из докомпьютерной эпохи
оптимизация под железо. Горячую часть кода упрощают и уменьшают, чтобы подольше не выходить за пределы аппаратных кешей. Данные читают и размещают последовательно, чтобы работали механизмы аппаратной предзагрузки на всех уровнях и аппаратные кеши не опустошались. Заранее прогревают программные кеши запросом или вычиткой данных, до того как запустится горячая часть кода. Также на железо хорошо ложится функциональный подход, коллекции и потоки: оно однотипно, последовательно, и содержит меньше условных операторов, чем традиционный код
размен циклов на время. Например сжатие больших кешей или отправляемых данных, если они хорошо жмутся: это дает дополнительную нагрузку на cpu, но ускоряет ввод/вывод в 5-10 раз. Жмут современные cpu быстро, хватает на большинство каналов ввода/вывода. Если cpu систематически недогружен и много текстового ввода/вывода, появляется возможность использовать такой размен
Просто комбинируя эти принципы можно ускорить код на 2-3 порядка практически на ровном месте
Вот и у меня странное антибликовое покрытие. Очень непривычно после матового пластика. Поверхность глянцевая, сама панель стеклянная, ожидается сильный зеркальный эффект, но на зеркало это не похоже, отражения есть, они четкие, но очень темные, на практике их не видно, они не мешают, и уловить их можно только на черных участках, и сами блики необычные, не слепят, и красиво рассыпаются на фрагменты.
Отражение солнечного луча от стеклянной панели
Похоже на описание "ночного режима". Есть из коробки во многих смартфонах, в win11 и KDE. По дефолту настраивается на время активности "от заката до рассвета". Как раз уводит картинки в янтарные оттенки.
KDE
Если позитрон живет в антивремени и существует в нашей вселенной, и известно что из квантовой пены могут возникать частицы и античастицы, то логично предположить что вселенная и антивселенная, время и антивремя, существуют в одном и том же пространстве, и квантовая пена как раз является проявлением этого. Далее логично предположить, что если вселенная и антивселенная находятся в одном пространстве, и существует такое явление как квантовая пена, свидетельствующее о том, что вселенная и антивселенная в каких-то местах в какие-то особые моменты могут взаимодействовать друг с другом, обмениваться материей в небольших точках, в которых нарушается равновесие, то, уже чисто по теории вероятности и закона больших чисел, где-то в пространстве просто обязаны существовать огромные регионы, где это самое равновесие нарушено, и вместо квантовой пены там должны наблюдаться квантовые штормы, с огромными объемами чужеродной материи и другими спецэффектами, такими например как источники антигравитации - если антигравитация хоть как-то может быть связана с антивселенной, то она будет именно там, в этих регионах.
https://habr.com/ru/articles/852900/ и https://habr.com/ru/companies/mts_ai/articles/831220/ - еще пара кирпичиков в фундамент нормального ассистента, возможность не только формировать ответы, но и взаимодействовать с окружением
Есть коврики специальные, котейки стряхивают на них почти все. Но не липнет минеральный наполнитель, который "без запаха", он всегда сухой, потому что быстро все впитывает и цементируется, а силикагель наверное липнет в любом случае, сомневаюсь что он так хорошо и быстро впитывает, как минеральный.
Можно той же самой сетке дать задание оценить свой ответ и доработать его. И дорабатывать пока оценка не станет удовлетворительной. Закольцовывать можно как внешним кодом, так и заставить саму сетку общаться с собой - такие промты тоже есть. Но если это на уровне промтов делать, побочка в том, что весь внутренний диалог сетки вываливается в чатик, так что лучше это прятать. Но наблюдать этот диалог конечно забавно - этакое раздвоение личности, исполнитель и ревизор в одном лице.
Без обид, но это уже попахивает коррупцией. Очень странно что за него еще и кто-то его работу делает.
Верно. Нужно уметь делегировать, грамотно использовать имеющиеся ресурсы в виде доступных специалистов, тогда достаточно будет лишь выстроить процессы, с учетом реалий на местах, и следить чтобы эти процессы не развалились. И останется лишь роль координатора. Но на практике задача эта не простая, люди не любят изменений, и активно будут противодействовать попыткам выстроить процессы. Нужны крепкие нервы, упертость, навыки убеждения и ведения переговоров. Толковых руководителей немного, но у кого получается, те идут далеко и ярко.
В линукс есть нативный llama.cpp и его производные: запускается сервер с нейронкой, и клиенты к нему шлют запросы. Клиенты есть консольные (сам llama.cpp такой предоставляет), браузерные, есть встроенные в популярные IDE плагинами. Нейронку можно выбрать самому из предустановленного списка или скачать любую другую - они все в стандартных форматах в интернете выложены. Все это работает локально, и доступно на любой современной видеокарте. Nvidia или amd - без разницы, сейчас оба вендора предоставляют равноценную поддержку ускорения нейронок.
Навигатор человека не заменит. Только недавно наблюдал такую картину: навигатор перед перекрестком показывает поворот на спуск, и это ожидаемый вариант, а через минуту навигатор потерялся и начал показывать окраины города, таксист в это время поехал прямо, а не на поворот на спуск, чего я не ожидал, но через 5 минут стало ясно что таксист просто хорошо знает этот район, и просто оптимизировал маршрут через мелкие улочки, а навигатор в себя пришел только уже перед остановкой. Так что тут сразу две проблемы навигатора проявились: он ненадежен и в любой момент может отказать, и он знает дорогу хуже опытного человека.
Нейросети в текущем виде не в состоянии не врать. Это их суть работы: синтез по матрице вероятностей, которую тренируют выдавать наиболее правдоподобные ответы. Но не наиболее правдивые - такой опции нет. Может быть нейросети каких-нибудь других архитектур, принципиально отличных от архитектуры языковых моделей, будут способны хотя бы в подобие мыслительного процесса и минимально осознанных ответов. Текущие же архитектуры на такое принципиально не способны, поэтому их удел пока - всякие развлечения, все что не требует точности и фактов.
Самый правильный вариант не всегда работает. Даже на крупных сайтах не всегда есть какие-либо удобные форматы использования, или же есть только устаревшие проблемные варианты. Разработчик может не разбираться в тонкостях конкретного linux, а их много. У него может просто отсутствовать мотивация поддерживать все это - чего уж говорить, таким страдают даже техногиганты с миллиардными бюджетами.
Так что правильнее, если пакеты под конкретный дистрибутив все же будет компилировать и собирать тот, кто работает с конкретным дистрибутивом.
На практике лучший опыт получается с софтом, исходники которого публично доступны в каком-нибудь репозитории, без регистрации и смс. Для такого софта доступен самый большой набор вариантов: от собственноручной сборки под свою ОС и машину, до прозрачного встраивания софта в любую пакетную базу: любой заинтересованный человек со стороны может подключить чужой публичный репозиторий к своей системе сборки пакетов, без какой-либо бюрократии и ограничений.
Такой софт доступен практически во всех пакетных базах, даже самых экзотических, и в каждой собирается по-своему: где-то статически, где-то под конкретные системные библиотеки доступные в конкретном релизе дистрбутива.
Сейчас много всяких dns со встроенными фильтрами от рекламы и трекинга, достаточно один раз озаботиться и прописать в роутер, и даже не замечаешь что реклама существует. Настолько не замечаешь, что перестаешь понимать на что жалуются люди, забываешь как выглядит интернет без фильтров
Что там с фильмом непонятно, но в играх с HDR разница видна: на SDR все хорошо, но нужно выбирать, или яркие источники света и вместо теней черное пятно, или пересвет но зато видно что в тенях делается, а с HDR доступны одновременно и яркие источники света и детали в тенях - динамический диапазон явно больше, можно заглядывать с улицы в пещеру или тоннель и видеть там что-то. Но некоторые игры это портят эффектом адаптации зрения: на ярких сценах через короткое время затемняют тени, а в темных сценах наоборот завышают яркость неба в окнах.
Также HDR сильно поднимает яркость точечных источников: например яркая-яркая луна ночью на фоне полутьмы окружения. На OLED это неплохо выглядит - там в таких сценах яркости могут быть огромные, хотя на всю панель такую яркость они выдать не способны, перегреваются мгновенно, полная яркость доступна только точечно.
Для 3D сейчас целый класс устройств появился - очки виртуальной реальности и сопутствующие аксессуары
А вот с HDR до сих пор не определились - нарожали 100500 стандартов, и нативно их никто не поддерживает. Что в windows, что в linux HDR прикрутили костылями. Много проблем на ровном месте с этим HDR. Хотя картинка конечно лучше - больше деталей в тенях. Но сейчас и моники научились тени высветлять из коробки, всякие игровые режимы на это и заточены. Хотелось бы чтобы стандарты HDR устаканились и все работало из коробки, как это сейчас с SDR происходит: кабель подключил и не заморачиваешься более.