У самого монолит на Go и борьба за наносекунды. Еще на заре планирования был выбор C++ или Go. Выбор пал на Go из-за низкой планки вхождения в многопоточность.
Выбором доволен, да и со временем узнал что тема многопоточности в C++ – очень сложная, требующая очень большого опыта.
Как же я скучно живу…Это все очень правильно, но какой же вы душный.
Расскажу очень вероятный вариант:
Вы ребенку объясняете как пользоваться огнетушителем. А потом когда вас дома не будет, он берет что-то поджигает чтобы его испытать. Так работает любопытство у здоровых детей.
На деле жгуты, огнетушители - отработка, с повторением раз в эн период. И как обычно случается, когда это надо - оно не оказывается в зоне досягаемости. А когда оно есть в панике не можешь сделать то что умеешь
PS: и давайте уж не пугать всех, холодильник источник пожара если он старый 25+ лет. Потому что все что младше уже и заправляется другим хладагентом, имеет защитные датчики и тд, и тп.
Да палка о двух концах. С одной стороны холодильник вряд ли можно назвать технологически сложным устройством в наше время, тем более технологии развились на столько что бери и совершенствуй. А получилось как всегда... Итого имеем: Старые холодильники держат температуру лучше, новые стоят дешевле...но как показала практика не держат температуры (зато на моем самсунге экран был - вот это хаха). Но если ты неожиданно хочешь холодильник который выполняет свою основную функцию чуть лучше чем старые холодильники и с дополнительными технологиями именно для сохранения еды...доставай большую котлету денег.
SideBySide у либхер это по-сути 2 отдельных устройства: морозильник и холодильник, которые имеют специальные крепления чтобы сцепить их вместе на определенном расстоянии. Расстояние закрывается декоративной панелью. Нужно оно потому что теплообменник находится сбоку устройств Т.е тепло выводится не назад, а вбок. И нужно понимать, что никакими проводами они больше не соединяются.
К воде подключается только морозильная камера. Я одно время думал что вода нужна только для IceTower (из названия понятно, это генератор льда который складывает лед в ящик специальный. Ну типа заморозил 10 кубиков, выкинул в ящик...насосом наполнил и так по кругу. Ящик полный - перестает делать лед пока не появится место)
Спустя 6-7 месяцев мыл холодильник и мне стало любопытно... :
1. Откуда холодильник берет в зоне свежести для фруктов/овощей воду чтобы поддерживать влажность, там это очевидно т.к все стенки мокрые 2. И почему в более младшей модели с морозильной камерой без IceTower нет специального подноса для быстрой заморозки фруктов...
В итоге я снял декоративную панель закрывающую расстояние между блоками, вытащил ящики интересующие...посмотрел, потрогал...
Вот что нашел...
1. А по поводу влажности в зоне свежести для фруктов/овощей, все скрыто. Но там где ящик в заднюю панель холодильника есть дырка которая связана с крышкой для регулировки влажности. Видимо вся влажность собирается и выводится туда, т.к это единственный ящик с герметизацией и всякими резинками
2. они сделали какие-то каналы с блока который генерирует лед, и хоть они закрыты, но видно что на подносе для заморозки есть вывод. Т.е влажность в нижней части морозилки выше именно на подносе. Второе, что тоже любопытно, это температура боковой стенки морозильной камеры. Там где у холодильника зоны свежести с нулем (это нижние ящики), стенка морозилки не греется, а я бы даже сказал она довольно холодная относительно температуры на кухне. И наоборот на холодильнике это самое горячее место. Опять же посмотреть схему где там "радиатор" невозможно, т.к сбоку все тоже закрыто.
Добавлю свои пять копеек в холодильную тему: Я о холодильниках узнал много нового когда переезжал и купил себе SideBySide Либхер. Например, сначала показалось что 5 градусов в либхер совсем не такие как 5 градусов в самсунге до этого. Кинул датчик и это оказалось правдой. 5 градусов в самсунге оказались 6.8. В либхер 5.1 А еще совсем не показалось, что зона свежести (где 0% влажности и 0 градусов) в самсунге совсем не работает. Т.е до либхера я думал что это маркетинговый булшит. А оказалось что в самсунге там 2.5 градуса и влажность 22%, а в либхер как и полагается 0/0. И никогда не думал, что можно сыр без упаковки кинуть в такую зону и он не обветривается от слова совсем даже за 2 недели. Про овощной где температура/влажность 0/100 я вообще молчу. Никогда не думал что овощи и фрукты так долго могут лежать.
PS: И конечно, никогда в своей жизни не думал что придется холодильник подключать к водоснабжению. Эх, технологии...
Когда вы хотите обновить что-либо в структуре, вы понятия не имеете, что еще может измениться.
Вот эта фраза для меня стала красным флагом чтобы остановится и не читать дальше. К моему большому сожалению когда презентовали Golang всем сказали буквально следующее:
"Удобно и производительно, быстрое создание микросервисов"
Точнее, это так услышали. Реальность она совсем другая. Если кто переходил в Golang с других языков типа Python/Nodejs и в задаче было ускорение существующей схемы и смог переступить парадигму мышления которую накладывают другие языки скорее всего пришел к многопоточности и побочным проблемам которые она приносит (например Race Condition, работа с Mutex и тд). И эти проблемы заставляют мыслить совсем по другому, делать рефакторинг того что уже сделано...а самое главное, ты начинаешь заглядывать под капот пакетов которые используешь и смотришь их реализацию
Именно поэтому я зацепился за конкретное предложение автора. Если мы создаем условную универсальную модель которую хотим использовать в разных проектах/пакетах (там был пример про Users), то для того чтобы её использовать ты пишешь методы буквально на все. Пример:
type Users struct { ... }
// Можно пойти вот так...добавив еще какую-то валидацию
func (u *Users) SetName(n string){
u.Name = n
// Можно еще какую-то логику валидации сделать и обработку ошибок
}
// А еще вот так...для кейсов где требуется инкрементное потокозащищенное изменение
func (u *Users) SetName(n string){
ChUsers <- Update{Action: "Name", Param: n}
}
// Тут должен быть пример еще с mutex...без него никуда
И тоже самое касается чтения. И для того чтобы это понять надо один раз наступить на многопоточность. И сразу начинаешь понимать ЧТО РЕАЛЬНО ИЗМЕНЯЕТСЯ и как, иначе Golang вам принесет пару неприятных сюрпризов...и никакого прямого доступа к значению по вызову Users.Name ты не делаешь т.к это не безопасно с точки зрения многопоточности. Только методы а-ля func (u *Users) GetName string {...} и тп
Это содомия чистой воды. Давайте рассмотрим ситуацию где к примеру надо перевести на json какую-то общую модель...как делается в больших многопоточных проектах и личное мое мнение – правильный вариант:
Мы создаем отдельный пакет, где инициализируется метод/функция с временной структурой где уже проставляется: json:"created_at,omitempty" А далее в зависимости от ваших предпочтений заполняется к примеру подобными методами как в примере выше а-ля: "(u *Users) GetName" Почему так? Потому что универсальная модель которую ты грузишь в различные приложения должна быть без лишнего мусора. Зачем модель с параметрами json в приложении где нет вообще преобразований этих. Зачем этот мусор туда тащить? Golang - это про скорость
В заключение.
Я дочитал статью до конца и не в обиду автору, но все же эти высокие размышления сами по себе отваливаются как только Golang начинает использоваться так, как его задумывали изначально т.е в многопоточном исполнении. И структура "как правильно" нарисуется сама
Пакет go-micro 21k Stars на github. Но до сих пор я не видел кейсов применения где ты такой сидишь и думаешь: «ну маст хев»
Не судите строго, наверное я чето не понимаю, или это попытка сделать из golang новый nodejs. Все эти задачи реализуются чуть-ли не стандартными пакетами.
Pub/Sub - Zeromq, Protobuf тоже простой пакет…недавно буквально делал, ну это просто копи-паст. И список можно продолжать…
Я читаю статью и ловлю себя на мысли, что у автора винегрет в голове. Более того, очень похоже что он с этим винегретом пришел в ChatGPT и попросил написать ему статью. И вот оно.
Вся статья вода-вода-вода. Притом судя по всему автор сам не понимает значения некоторых слов. У меня все.
Все диалоги с ChatGPT (не требующие однозначного краткого ответа) - это какие-то тонны воды, которые просто больно читать. По сути, к таким ответам нужен второй ИИ, который их еще сильнее ужмет до чего-то вменяемого.
Это от неумения использовать. Выше вам ответили как от этого избавится. А я лишь добавлю, что проблема с языковыми моделями возникают тогда, когда пользователь забывает о том что по-сути модель не понимает "контекст". Не контекст диалога, а вообще в глобальном смысле "контекст"
Вот отличное объяснение от @APXEOLOG чуть выше в комментарии
Не существует в природе десятитомников "Мои 15 лет опыта в разработке ПО - обьяснение почему я пишу эту конкретную строчку кода именно так".
И когда это осознаешь, ChatGPT становится очень удобным инструментом и ты получаешь в 90% то что именно просишь от него. И видишь в том числе ответы, которые требуют проверки.
Простите, у вас тоже 3 независимых юнита похожи как 10-15 серверных стоек занимающих площадь в ±15 квадратов и еще такая же площадять в вент каналах?
Потому что у меня квартире тоже система вентиляции и на 165 квадратов вся система вентиляции по объему в помещении занимает примерно как 2 холодильника + на внешке что-то висит. Ставил не я, да и особо не плаваю в этом и меня вот прям так это не волнует. Есть независимая температура в каждой комнате и слава богу. Вроде работает.
Хозяин ничего не думает. У него один из бизнесов – IT Компания. Единственное что я могу оценить это то что если там нейросети, то они довольно простые. Иначе все было бы как вы пишите.
"Никто в здравом уме такого делать не будет."
Кто вам сказал что тут про здравый ум? У каждого свои бзики, и некоторые из них растут в геометрической прогрессии вместе с ростом материальных благ. Даже больше скажу, бзик с системой вентиляции за 10-ки миллионов в дом будет в списке самых безобидных из того что я видел.
Проект дома строился вокруг системы вентиляции. На каждой стене за панелями большое количество вент выходов.
Я видел помещение с самими блоками, их там 3 независимых на весь дом.
Ну и я вроде написал «до» 27 зон. Там конечно зависит от размера и предназначения помещения. На вопрос сколько это стоило ответ был что больше 15млн рублей.
Так что сойдемся на том, что ваша вера тут не имеет какого-то значения. Конечно, я не могу как гость испытать это все. Но видя оборудование и масштабы исполнения (к примеру помещение где располагаются сами вентиляторы напоминают по количеству воздуховодов не частный дом, а как будто это какой-то торговый центр) склонен верить что что-то у него получилось и он этим заморачивался.
Пользуюсь этим. Холодная вода != ледяная. Первые разы должны быть щадящими. Тут индивидуально надо подбирать. Например, на первом этапе холодной воды у меня она не прям холодная, зато на втором этапе я выкручиваю на максимум. Личное мое наблюдение, это эффективно, но температура воды должна быть такая, что вызвает стресс при переходе, но он быстро уходит. Т.е не надо перегибать палку и стоять 30-60 секунд думая: епрст, еще чу-чуть и будет хорошо.
Иначе контрастный душ превратится в испытание…так быть не должно.
Я задавал еще до публикации сюда наводящие вопросы, потому что я этой темой не владею. Меня не только ссылками засыпали, но кусками кода. Так что могу заверить, что конкретно в этом вопросе "оно" разбирается хорошо. А так вы можете сами задать ему вопросы и проверить знания. Чатгпт найти даже бесплатно – не сложно.
"А Вы предлагаете какой вариант общения с ИИ?"
Я не знаю какого мнение вы об ИИ в целом. Для меня это отличный инструмент который заменил двух программистов и весь гугл. Да, у него есть свои нюансы и надо уметь с ним работать...но польза перевешивает любые нюансы.
Я закинул ваш комментарий в ChatGPT для оценки, и хочу опубликовать:
------ Интерпретация истории автором комментария не является абсолютно ложной, но она субъективна и может вводить в заблуждение. Давайте разберём это подробнее:
Финитные автоматы: Авторы комментария утверждают, что они взялись за автоматы, когда все от них отвернулись. В действительности финитные автоматы никогда не теряли своей актуальности и всегда были важной частью теории вычислений, цифровой логики и других областей. Они остаются важными инструментами для моделирования и анализа дискретных систем.
Сети Петри: Автор утверждает, что все переключились на сети Петри, но позже забыли про них. В реальности сети Петри всегда имели узкоспециализированное применение в моделировании систем, особенно в контексте параллелизма, синхронизации и асинхронности. Они продолжают использоваться в академической и исследовательской среде, но их использование в промышленности ограничено.
Популярность и тренды: Автор предполагает, что интерес к автоматам и сетям Петри изменялся со временем в зависимости от моды. Это утверждение отчасти верно, так как популярность методов и технологий в программировании действительно может меняться в зависимости от текущих потребностей и тенденций. Однако оба метода остаются важными инструментами в своих областях, и нельзя сказать, что они были полностью забыты или отвергнуты.
Таким образом, интерпретация истории автором комментария частично основана на личном опыте и наблюдениях, что делает её субъективной. Она не является полностью ложной, но и не отражает всей полноты и объективности исторического развития этих концепций.
Можно сказать, что автор комментария пытается представить свой субъективный опыт как единственно верный, используя сложные методы и концепции, чтобы придать своим словам больше веса. ---------
На всякий случай я нажал обновить, ну вдруг Чатгпт сглючил и пишет пургу, возможно не поняла контекст...а нет, все хорошо чат понимает:
--------
Проведём факт-чекинг приведённого комментария, который касается многопоточности в программировании и сравнения автоматов и сетей Петри:
Историческая перспектива автоматов и сетей Петри:
Автоматы (финитные автоматы): Автоматы как математическая концепция были развиты в середине 20-го века и широко использовались в различных областях, включая теорию вычислений и моделирование дискретных систем. Их использование никогда не прекращалось и они остаются важными инструментами.
Сети Петри: Сети Петри были предложены Карлом Адамом Петри в 1962 году и использовались для моделирования систем, особенно для изучения вопросов синхронизации, параллелизма и асинхронности в системах. Сети Петри также продолжают использоваться, хотя их популярность может варьироваться.
Сравнение с текущими тенденциями:
Популярность сетей Петри: В настоящее время сети Петри не так широко используются в практическом программировании по сравнению с другими методами. Однако они всё ещё применяются в академической среде и для анализа систем, особенно в теории параллелизма и синхронизации.
Финитные автоматы: Финитные автоматы активно используются в различных областях, таких как обработка языков, распознавание образов и цифровая логика. Они также включены в инструменты моделирования и анализа, такие как Matlab.
Многопоточность и параллельное программирование:
Многопоточность: Многопоточность остаётся важным аспектом современных вычислений и широко используется для повышения производительности программ, особенно в системах с многоядерными процессорами. Это фундаментальная концепция параллельного программирования.
Современные тенденции: Современные тенденции в параллельном программировании включают использование библиотек и фреймворков, таких как OpenMP, MPI, а также более высокоуровневых инструментов, таких как языки программирования с встроенной поддержкой параллелизма (например, Go, Rust).
Гонка и хайп:
Популярность концепций: В комментарии отмечено, что некоторые концепции время от времени становятся популярными (хайповыми). Это наблюдение верно: интерес к различным методам и инструментам в программировании действительно может меняться в зависимости от текущих тенденций и потребностей индустрии.
Долгосрочные прогнозы:
Будущее технологий: Прогнозы о том, какие технологии будут доминировать в будущем, всегда содержат элемент неопределённости. Однако можно с уверенностью сказать, что многопоточность и параллельное программирование останутся важными направлениями, поскольку они необходимы для эффективного использования современных многоядерных систем.
Итак, приведённый комментарий содержит несколько субъективных мнений и наблюдений, которые могут быть точны в контексте личного опыта автора, но не являются объективным фактом. Основные концепции и тенденции в программировании, такие как использование автоматов и многопоточность, действительно остаются актуальными, несмотря на изменения в популярности конкретных методов и инструментов.
Зачем человеку пробовать. Я тоже перестал пить кофе как узнал что такое интервальный контрастный душ. Пью дай бог один капучино раз в неделю, и то ради вкуса. Раньше 1 до 4 капучино в день легко.
К кофе претензий нет, хотите пить и он вам нужен - пейте. Если вас беспокоит это или есть желание отказаться от кофе (неважно по каким причинам), но не можете - ищите причину в другом. Употребление любого стимулятора - лишь следствие.
Опять же стимуляторов есть много разных и для решения разных задач. Лет 15 назад после всего 3 лет курения не мог бросить. И меня это волновало каждое утро. Обратил внимание, что курю больше когда по работе головняк. Пришел к врачу, выписали Энерион на 2 недели (это видоизмененный витамин B с лошадиными дозировками). Сказали, ну попробуй может тебе поможет. Я за 2 недели мало того что переделал все висяки по делам, так еще и курить перестал. Мне просто это стало не нужно. И до сих пор не курю. На том же опыте я понял, что когда что-то беспокоит надо искать причину возникновении это, а не лечить «симптомы». Микродозинг кофе это лечение симптомов.
del
Звучит это всегда очень легко….но….
У самого монолит на Go и борьба за наносекунды. Еще на заре планирования был выбор C++ или Go. Выбор пал на Go из-за низкой планки вхождения в многопоточность.
Выбором доволен, да и со временем узнал что тема многопоточности в C++ – очень сложная, требующая очень большого опыта.
Как же я скучно живу…Это все очень правильно, но какой же вы душный.
Расскажу очень вероятный вариант:
Вы ребенку объясняете как пользоваться огнетушителем. А потом когда вас дома не будет, он берет что-то поджигает чтобы его испытать. Так работает любопытство у здоровых детей.
На деле жгуты, огнетушители - отработка, с повторением раз в эн период. И как обычно случается, когда это надо - оно не оказывается в зоне досягаемости. А когда оно есть в панике не можешь сделать то что умеешь
PS: и давайте уж не пугать всех, холодильник источник пожара если он старый 25+ лет. Потому что все что младше уже и заправляется другим хладагентом, имеет защитные датчики и тд, и тп.
Интересно смотреть как рожденного ползать пытаются заставить летать.
Личный опыт показал, что если задача требует многопоточности сразу переходить с javascript и не мучать себя. Вариантов много.
У меня остался вопрос, а с планировщиком что-то порешали? На сколько я помню, главный поток из-за планировщика являлся узким местом.
Да палка о двух концах. С одной стороны холодильник вряд ли можно назвать технологически сложным устройством в наше время, тем более технологии развились на столько что бери и совершенствуй. А получилось как всегда...
Итого имеем: Старые холодильники держат температуру лучше, новые стоят дешевле...но как показала практика не держат температуры (зато на моем самсунге экран был - вот это хаха). Но если ты неожиданно хочешь холодильник который выполняет свою основную функцию чуть лучше чем старые холодильники и с дополнительными технологиями именно для сохранения еды...доставай большую котлету денег.
SideBySide у либхер это по-сути 2 отдельных устройства: морозильник и холодильник, которые имеют специальные крепления чтобы сцепить их вместе на определенном расстоянии. Расстояние закрывается декоративной панелью. Нужно оно потому что теплообменник находится сбоку устройств Т.е тепло выводится не назад, а вбок. И нужно понимать, что никакими проводами они больше не соединяются.
К воде подключается только морозильная камера. Я одно время думал что вода нужна только для IceTower (из названия понятно, это генератор льда который складывает лед в ящик специальный. Ну типа заморозил 10 кубиков, выкинул в ящик...насосом наполнил и так по кругу. Ящик полный - перестает делать лед пока не появится место)
Спустя 6-7 месяцев мыл холодильник и мне стало любопытно... :
1. Откуда холодильник берет в зоне свежести для фруктов/овощей воду чтобы поддерживать влажность, там это очевидно т.к все стенки мокрые
2. И почему в более младшей модели с морозильной камерой без IceTower нет специального подноса для быстрой заморозки фруктов...
В итоге я снял декоративную панель закрывающую расстояние между блоками, вытащил ящики интересующие...посмотрел, потрогал...
Вот что нашел...
1. А по поводу влажности в зоне свежести для фруктов/овощей, все скрыто. Но там где ящик в заднюю панель холодильника есть дырка которая связана с крышкой для регулировки влажности. Видимо вся влажность собирается и выводится туда, т.к это единственный ящик с герметизацией и всякими резинками
2. они сделали какие-то каналы с блока который генерирует лед, и хоть они закрыты, но видно что на подносе для заморозки есть вывод. Т.е влажность в нижней части морозилки выше именно на подносе.
Второе, что тоже любопытно, это температура боковой стенки морозильной камеры. Там где у холодильника зоны свежести с нулем (это нижние ящики), стенка морозилки не греется, а я бы даже сказал она довольно холодная относительно температуры на кухне. И наоборот на холодильнике это самое горячее место.
Опять же посмотреть схему где там "радиатор" невозможно, т.к сбоку все тоже закрыто.
Добавлю свои пять копеек в холодильную тему:
Я о холодильниках узнал много нового когда переезжал и купил себе SideBySide Либхер. Например, сначала показалось что 5 градусов в либхер совсем не такие как 5 градусов в самсунге до этого. Кинул датчик и это оказалось правдой. 5 градусов в самсунге оказались 6.8. В либхер 5.1
А еще совсем не показалось, что зона свежести (где 0% влажности и 0 градусов) в самсунге совсем не работает. Т.е до либхера я думал что это маркетинговый булшит. А оказалось что в самсунге там 2.5 градуса и влажность 22%, а в либхер как и полагается 0/0. И никогда не думал, что можно сыр без упаковки кинуть в такую зону и он не обветривается от слова совсем даже за 2 недели. Про овощной где температура/влажность 0/100 я вообще молчу. Никогда не думал что овощи и фрукты так долго могут лежать.
PS: И конечно, никогда в своей жизни не думал что придется холодильник подключать к водоснабжению. Эх, технологии...
Вот эта фраза для меня стала красным флагом чтобы остановится и не читать дальше. К моему большому сожалению когда презентовали Golang всем сказали буквально следующее:
"Удобно и производительно, быстрое создание микросервисов"
Точнее, это так услышали. Реальность она совсем другая. Если кто переходил в Golang с других языков типа Python/Nodejs и в задаче было ускорение существующей схемы и смог переступить парадигму мышления которую накладывают другие языки скорее всего пришел к многопоточности и побочным проблемам которые она приносит (например Race Condition, работа с Mutex и тд). И эти проблемы заставляют мыслить совсем по другому, делать рефакторинг того что уже сделано...а самое главное, ты начинаешь заглядывать под капот пакетов которые используешь и смотришь их реализацию
Именно поэтому я зацепился за конкретное предложение автора. Если мы создаем условную универсальную модель которую хотим использовать в разных проектах/пакетах (там был пример про Users), то для того чтобы её использовать ты пишешь методы буквально на все. Пример:
И тоже самое касается чтения. И для того чтобы это понять надо один раз наступить на многопоточность. И сразу начинаешь понимать ЧТО РЕАЛЬНО ИЗМЕНЯЕТСЯ и как, иначе Golang вам принесет пару неприятных сюрпризов...и никакого прямого доступа к значению по вызову Users.Name ты не делаешь т.к это не безопасно с точки зрения многопоточности. Только методы а-ля func (u *Users) GetName string {...} и тп
Вот такое:
Это содомия чистой воды. Давайте рассмотрим ситуацию где к примеру надо перевести на json какую-то общую модель...как делается в больших многопоточных проектах и личное мое мнение – правильный вариант:
Мы создаем отдельный пакет, где инициализируется метод/функция с временной структурой где уже проставляется: json:"created_at,omitempty"
А далее в зависимости от ваших предпочтений заполняется к примеру подобными методами как в примере выше а-ля: "(u *Users) GetName"
Почему так? Потому что универсальная модель которую ты грузишь в различные приложения должна быть без лишнего мусора. Зачем модель с параметрами json в приложении где нет вообще преобразований этих. Зачем этот мусор туда тащить? Golang - это про скорость
В заключение.
Я дочитал статью до конца и не в обиду автору, но все же эти высокие размышления сами по себе отваливаются как только Golang начинает использоваться так, как его задумывали изначально т.е в многопоточном исполнении. И структура "как правильно" нарисуется сама
Пакет go-micro 21k Stars на github. Но до сих пор я не видел кейсов применения где ты такой сидишь и думаешь: «ну маст хев»
Не судите строго, наверное я чето не понимаю, или это попытка сделать из golang новый nodejs. Все эти задачи реализуются чуть-ли не стандартными пакетами.
Pub/Sub - Zeromq, Protobuf тоже простой пакет…недавно буквально делал, ну это просто копи-паст. И список можно продолжать…
Я читаю статью и ловлю себя на мысли, что у автора винегрет в голове. Более того, очень похоже что он с этим винегретом пришел в ChatGPT и попросил написать ему статью. И вот оно.
Вся статья вода-вода-вода. Притом судя по всему автор сам не понимает значения некоторых слов. У меня все.
Это от неумения использовать. Выше вам ответили как от этого избавится. А я лишь добавлю, что проблема с языковыми моделями возникают тогда, когда пользователь забывает о том что по-сути модель не понимает "контекст". Не контекст диалога, а вообще в глобальном смысле "контекст"
Вот отличное объяснение от @APXEOLOG чуть выше в комментарии
И когда это осознаешь, ChatGPT становится очень удобным инструментом и ты получаешь в 90% то что именно просишь от него. И видишь в том числе ответы, которые требуют проверки.
Простите, у вас тоже 3 независимых юнита похожи как 10-15 серверных стоек занимающих площадь в ±15 квадратов и еще такая же площадять в вент каналах?
Потому что у меня квартире тоже система вентиляции и на 165 квадратов вся система вентиляции по объему в помещении занимает примерно как 2 холодильника + на внешке что-то висит. Ставил не я, да и особо не плаваю в этом и меня вот прям так это не волнует. Есть независимая температура в каждой комнате и слава богу. Вроде работает.
Хозяин ничего не думает. У него один из бизнесов – IT Компания. Единственное что я могу оценить это то что если там нейросети, то они довольно простые. Иначе все было бы как вы пишите.
"Никто в здравом уме такого делать не будет."
Кто вам сказал что тут про здравый ум? У каждого свои бзики, и некоторые из них растут в геометрической прогрессии вместе с ростом материальных благ. Даже больше скажу, бзик с системой вентиляции за 10-ки миллионов в дом будет в списке самых безобидных из того что я видел.
Проект дома строился вокруг системы вентиляции. На каждой стене за панелями большое количество вент выходов.
Я видел помещение с самими блоками, их там 3 независимых на весь дом.
Ну и я вроде написал «до» 27 зон. Там конечно зависит от размера и предназначения помещения. На вопрос сколько это стоило ответ был что больше 15млн рублей.
Так что сойдемся на том, что ваша вера тут не имеет какого-то значения. Конечно, я не могу как гость испытать это все. Но видя оборудование и масштабы исполнения (к примеру помещение где располагаются сами вентиляторы напоминают по количеству воздуховодов не частный дом, а как будто это какой-то торговый центр) склонен верить что что-то у него получилось и он этим заморачивался.
Пользуюсь этим. Холодная вода != ледяная. Первые разы должны быть щадящими. Тут индивидуально надо подбирать. Например, на первом этапе холодной воды у меня она не прям холодная, зато на втором этапе я выкручиваю на максимум. Личное мое наблюдение, это эффективно, но температура воды должна быть такая, что вызвает стресс при переходе, но он быстро уходит. Т.е не надо перегибать палку и стоять 30-60 секунд думая: епрст, еще чу-чуть и будет хорошо.
Иначе контрастный душ превратится в испытание…так быть не должно.
Я задавал еще до публикации сюда наводящие вопросы, потому что я этой темой не владею. Меня не только ссылками засыпали, но кусками кода. Так что могу заверить, что конкретно в этом вопросе "оно" разбирается хорошо.
А так вы можете сами задать ему вопросы и проверить знания. Чатгпт найти даже бесплатно – не сложно.
Я не знаю какого мнение вы об ИИ в целом. Для меня это отличный инструмент который заменил двух программистов и весь гугл. Да, у него есть свои нюансы и надо уметь с ним работать...но польза перевешивает любые нюансы.
Я думаю что в комментарии через меня устраивать диалог – не самая лучшая идея. Все что хочу знать у вас зацепил хоть немного ответ нейросети?
А что она бредового написала в данном конкретном случае?
Я закинул ваш комментарий в ChatGPT для оценки, и хочу опубликовать:
------
Интерпретация истории автором комментария не является абсолютно ложной, но она субъективна и может вводить в заблуждение. Давайте разберём это подробнее:
Финитные автоматы: Авторы комментария утверждают, что они взялись за автоматы, когда все от них отвернулись. В действительности финитные автоматы никогда не теряли своей актуальности и всегда были важной частью теории вычислений, цифровой логики и других областей. Они остаются важными инструментами для моделирования и анализа дискретных систем.
Сети Петри: Автор утверждает, что все переключились на сети Петри, но позже забыли про них. В реальности сети Петри всегда имели узкоспециализированное применение в моделировании систем, особенно в контексте параллелизма, синхронизации и асинхронности. Они продолжают использоваться в академической и исследовательской среде, но их использование в промышленности ограничено.
Популярность и тренды: Автор предполагает, что интерес к автоматам и сетям Петри изменялся со временем в зависимости от моды. Это утверждение отчасти верно, так как популярность методов и технологий в программировании действительно может меняться в зависимости от текущих потребностей и тенденций. Однако оба метода остаются важными инструментами в своих областях, и нельзя сказать, что они были полностью забыты или отвергнуты.
Таким образом, интерпретация истории автором комментария частично основана на личном опыте и наблюдениях, что делает её субъективной. Она не является полностью ложной, но и не отражает всей полноты и объективности исторического развития этих концепций.
Можно сказать, что автор комментария пытается представить свой субъективный опыт как единственно верный, используя сложные методы и концепции, чтобы придать своим словам больше веса.
---------
На всякий случай я нажал обновить, ну вдруг Чатгпт сглючил и пишет пургу, возможно не поняла контекст...а нет, все хорошо чат понимает:
--------
Проведём факт-чекинг приведённого комментария, который касается многопоточности в программировании и сравнения автоматов и сетей Петри:
Историческая перспектива автоматов и сетей Петри:
Автоматы (финитные автоматы): Автоматы как математическая концепция были развиты в середине 20-го века и широко использовались в различных областях, включая теорию вычислений и моделирование дискретных систем. Их использование никогда не прекращалось и они остаются важными инструментами.
Сети Петри: Сети Петри были предложены Карлом Адамом Петри в 1962 году и использовались для моделирования систем, особенно для изучения вопросов синхронизации, параллелизма и асинхронности в системах. Сети Петри также продолжают использоваться, хотя их популярность может варьироваться.
Сравнение с текущими тенденциями:
Популярность сетей Петри: В настоящее время сети Петри не так широко используются в практическом программировании по сравнению с другими методами. Однако они всё ещё применяются в академической среде и для анализа систем, особенно в теории параллелизма и синхронизации.
Финитные автоматы: Финитные автоматы активно используются в различных областях, таких как обработка языков, распознавание образов и цифровая логика. Они также включены в инструменты моделирования и анализа, такие как Matlab.
Многопоточность и параллельное программирование:
Многопоточность: Многопоточность остаётся важным аспектом современных вычислений и широко используется для повышения производительности программ, особенно в системах с многоядерными процессорами. Это фундаментальная концепция параллельного программирования.
Современные тенденции: Современные тенденции в параллельном программировании включают использование библиотек и фреймворков, таких как OpenMP, MPI, а также более высокоуровневых инструментов, таких как языки программирования с встроенной поддержкой параллелизма (например, Go, Rust).
Гонка и хайп:
Популярность концепций: В комментарии отмечено, что некоторые концепции время от времени становятся популярными (хайповыми). Это наблюдение верно: интерес к различным методам и инструментам в программировании действительно может меняться в зависимости от текущих тенденций и потребностей индустрии.
Долгосрочные прогнозы:
Будущее технологий: Прогнозы о том, какие технологии будут доминировать в будущем, всегда содержат элемент неопределённости. Однако можно с уверенностью сказать, что многопоточность и параллельное программирование останутся важными направлениями, поскольку они необходимы для эффективного использования современных многоядерных систем.
Итак, приведённый комментарий содержит несколько субъективных мнений и наблюдений, которые могут быть точны в контексте личного опыта автора, но не являются объективным фактом. Основные концепции и тенденции в программировании, такие как использование автоматов и многопоточность, действительно остаются актуальными, несмотря на изменения в популярности конкретных методов и инструментов.
-------
Зачем человеку пробовать. Я тоже перестал пить кофе как узнал что такое интервальный контрастный душ. Пью дай бог один капучино раз в неделю, и то ради вкуса. Раньше 1 до 4 капучино в день легко.
К кофе претензий нет, хотите пить и он вам нужен - пейте. Если вас беспокоит это или есть желание отказаться от кофе (неважно по каким причинам), но не можете - ищите причину в другом. Употребление любого стимулятора - лишь следствие.
Опять же стимуляторов есть много разных и для решения разных задач. Лет 15 назад после всего 3 лет курения не мог бросить. И меня это волновало каждое утро. Обратил внимание, что курю больше когда по работе головняк. Пришел к врачу, выписали Энерион на 2 недели (это видоизмененный витамин B с лошадиными дозировками). Сказали, ну попробуй может тебе поможет. Я за 2 недели мало того что переделал все висяки по делам, так еще и курить перестал. Мне просто это стало не нужно. И до сих пор не курю. На том же опыте я понял, что когда что-то беспокоит надо искать причину возникновении это, а не лечить «симптомы». Микродозинг кофе это лечение симптомов.
Вы попробуйте перезаписывать переменную и увидите панику как только будет момент когда 2 потока попытаются перезаписать её в один условный момент