И если правки в любой проект не были внесены вовремя, виноваты в этом не разработчики PHP, а разработчики, занимающиеся развитием проекта и не пожелавшие вовремя внести небольшие изменения в код.
Ну да. В идеальном мире, в больших проектах. А если это типичный "магазинчик на Битриксе", то там иногда даже постоянных разработчиков нет. Просто раз в полгода-год кого-то находят, он реализует накопившиеся желания клиента (чаще всего - максимально через одно место) и на этом про код все опять забывают.
Естественно, что в один "прекрасный" момент клиент решает обновиться - его же Битрикс предупреждает постоянно, что пора. Переключает версию php, нормально обновляется - он же в админке, там всё хорошо. И тут-то и наступает ж... - потому что публичная часть уже перестала нормально работать, а откатывать обновления Битрикс не умеет до сих пор (молодой же проект, всего 20 лет ему!). Бэкапов тоже обычно нет как класса.
И вот тут прихожу я - буквально к руинам...
Последней же версией, при переходе на которую могла потребоваться радикальная переделка старого кода, была PHP 5.4
Ага. Старый код переставал работать при переходе 5.4 -> 5.6 5.6 -> 7.0 7.1 -> 7.2 7.2 -> 7.3 7.3 -> 8.0 8.0 -> 8.2 Тут уже буквально можно на пальцах одной руки посчитать те версии, которые не ломали старый код :)
Пример JavaScript, в котором "совместимость" возвели в религию, показывает, что это приводит лишь к бессмысленному раздуванию языка и тиражированию низкокачественного кода.
Если люди хотят писать некачественный код - они будут это делать на любом языке несмотря на любые ограничения. Ладно бы php/js были бы компилируемыми - сделал раз и оно будет работать всегда...
В современном мире несовместимости между версиями языка - не исключение из правил, а норма.
Это печально все-таки. Ну я понимаю что прогресс и всё такое. Но как-то всё-таки хотелось бы иметь соотв. настройки, чтобы совместимость не ломалась бы. Потому что даже в C++ проблемы, если взять код, которому лет 10-20 и попытаться его собрать на свежей версии компилятора.
Стоп. Этот плохой код написал не я. И написан он был очень давно - 5, иногда даже 10 лет назад. Еще во времена php 5.4-5.6 или 7.х. И в то время этот код был полностью в рамках той версии языка.
А теперь это всё, внезапно, разработчики языка просто взяли и сломали - причем даже не оставив возможности как-то вернуть "как было" хотя бы даже и на время.
Вы никогда не правили огромный старый код (который вы раньше даже в глаза не видели!) в режиме ошпаренной кошки и когда "надо еще вчера"? Попробуйте, просто незабываемые ощущения.
А можно сразу попытаться создать более устойчивую архитектуру и надежный код, тогда миграция с 5.4 до 8.5 пройдет легче.
Можно, да. Но тогда надо или полностью всё самому писать - или брать какой-то фреймворк. Но лет через 10 вы всё равно придёте к тому же самому - "чтобы обновить на новый php надо переписать вообще всё".
Ну или можно просто забить на обновления, значит язык продукта это не php, а его подмножество, версии 5.4.
И потом к вам прилетит очередная вирусня и будет ещё хуже.
Ну так проблема не в том, что "сдуру", а в том, что никакого контроля за тем, что выдаст cms у нас нет. Сегодня там одно, завтра они что-то поменяли, мы битрикс обновили и сайт лёг - причем иногда вообще весь.
Если вам так нравится анархия классического php, то зачем обновляетесь?
Обновляемся не от хорошей жизни, а потому что Битрикс обновлять надо. А его обновлять надо, потому что уязвимости + он безальтернативно теперь требует конкретные версии php и выбора, что ставить, уже по сути и нет.
А если обновляетесь, то почему не пишите правильный код и не изолируете свои части кода?
Потому что это Битрикс. Потому что там ВЕСЬ код вот так писался уже лет двадцать подряд - то есть у нас огромная куча унаследованного кода, который физически невозможно корректно переделать. Вы вообще объемы представляете? Базовая установка магазина на Битриксе - это 80 ТЫСЯЧ файлов. Плюс ещё сам шаблон сайта - это тоже несколько сотен, если не тысяча файлов, равномерно размазанных по всему диску.
И когда после обновления сайт ложится (весь или частично), то ко мне прибегает очередной клиент с криками "всё пропало!!!" и надо это вот как-то чинить, причем срочно. А там, бонусом, поверх битрикса еще какой-нить шаблон могли накатить, типа Аспро (а он сам по себе размерами как ещё один Битрикс), который потом несколько лет дописывали сами - и его теперь невозможно обновить, потому что вообще никто уже не помнит и не знает что там и где в нём дописывалось. И там старый код, который падает просто везде - в самых неожиданных местах. Причем одна страница товара работает нормально, а другая - падает, потому что там картинки нет. Или какое-то поле не заполнено было - причем необязательное.
И таких сайтов, замечу - большинство. Не, ну может где-то и есть нормальные - но такие ко мне не приходят, приходят вот эти.
А для говнокода и веселья всегда можно поставить error_reporting(0) и глупо хихикать.
Разработчики php теперь умные и теперь грохают всё сразу, а не как раньше - "пищит, но работает".
Ну я ж говорю - это всё замечательно, пока вы работаете с php так же, как вы работаете в других языках, типа того же С#. Т.е. полноценная среда разработки, отладчик и всё такое.
По факту же, как-то так выходит, что когда мы работаем с cms типа того же Битрикса - там не то что про отладчик речи не идет, там даже полноценное автодополнение кода не работает обычно. И про все крутые фичи работы с классами в IDE можно тоже смело забыть. И вообще замечательно, если хотя бы ftp есть, а не приходится файлы править во встроенном редакторе...
Ну т.е. это всё по удобству получается где-то на уровне как если код в Notepad++ править. Подсветка синтаксиса есть, что-то из текущего файла в автодополнении иногда работает - и это всё.
И когда на вот это вот всё притягиваются ещё и классы и, не дай боги, работа с orm - это просто больно. Потому что кодить это приходится вообще на ощупь. И отладчик не подключить - его нет, он выключен. И даже банальный print_r в Битриксе раньше выкидывал хоть и большой массив, но его хотя бы можно было глазами прочитать - а теперь он выкидывает дамп объекта, у которого часть полей рекурсивно ссылаются сами на себя, а часть требуют геттеров-сеттеров, причем неизвестно каких (потому что даже в документации ничего нет - Битрикс вообще очень не любит обновлять свою документацию). И еще он тебе вываливает портянку мегабайт на 30 чистого текста, от которой даже браузер на мощном компе офигевает. У-удобство.
Что касается вашего примера, то сломать его легко и просто:
$a = new DateTime();
var_dump(isset($a['b']['c']['d']['e']['f']));
*Fatal error: Uncaught Error: Cannot use object of type DateTime as array in /home/user/scripts/code.php:3*
Просто, в отличие от "полноценных" приложений на том же c# - мы, в общем случае, в принципе никак не контролируем, что там к нам в код прилетает. Особенно когда у нас это всё завёрнуто в большую cms.
И там, где раньше php был толерантным к кривым данным и просто работал, теперь необходимо делать кучу проверок. И это, ну, неудобно. Потому что, они, ну, не очень-то и нужны - за правильность данных отвечает сама cms, там точно ничего страшного не прилетит. А если тип будет не тот, то php сам автоматом это сконвертирует туда-сюда правильно в большинстве случаев - ну т.е. конвертировал. А теперь надо делать это тоже самому, вручную.
Неа. На практике теперь в php 8.1+ оно чаще всего просто падает с ошибкой обращения к несуществующему элементу массива. Причем, так как у нас много уровней вложенности - то проверять на существование теперь надо их все. И нельзя просто так проверить только самый последний в цепочке даже через какой-нить isset() или empty() - потому что оно тоже падает, если на предыдущем уровне нужного элемента массива тоже нет.
Поверх всего это ещё висит вечная ошибка с "Warning: count(): Parameter must be an array or an object that implements Countable" которая напрочь блокирует любой старый код (все версии php ранее 8.1), где в условиях писали что-то типа if(count($a) && ...);.
Самую мякотку сюда добавляет еще и уникально-php-шная работа функций empty() и isset(), которые возвращают разные результаты в зависимости от того, что там внутри переменной - значение, объект, null или явно заданное false. И это тоже надо перепроверять доп. условием, иначе count() после isset() опять-таки может уронить всю страницу сайта...
В общем, я это всё к тому, что в текущем виде получилась как-то неудобная фигня. И определенно нужен какой-то особый синтаксический сахар вводить, чтобы это всё было как-то более удобно писать в коде.
Я согласен с тем, что для сложных систем и ООП, и строгая типизация - нужны. Проблема в том, что в значительном количестве мест, где сейчас используется php, это всё просто не нужно. Вообще не нужно. Там, иногда, даже код на функции разбивать - уже избыточно.
Ну и у Wordpress'а те же самые проблемы, что и у Битрикса - всё те же постоянные приседания вокруг null и типов.
Просто потому что php работает с внешними данными, которые вообще неизвестно откуда и как в этот код прилетели. И там может быть что угодно - числа, строки, массивы, объекты, base64, json. И в огромном количестве случаев всё это просто пролетает через код дальше - туда, где оно и будет реально обработано и проверено перед выводом (чтобы всякие CSRF-ошибки не словить).
И без строгой типизации все это довольно красиво программилось. А теперь каждое обращение к любым данным надо огораживать заборчиком из кучи условий и проверок.
Вот конкретно в Битриксе, раньше я мог тупо проверить факт наличия пути к картинке и вывести тег img. А теперь мне надо проверить, что массив - это массив, что он не пуст. Что в нем есть соотв. индекс. Что по этому индексу лежит не пустой массив. И только потом я смогу эту несчастную картинку вывести. А всё потому что картинка эта лежит на третьем-четвертом уровне вложенности в массиве. И может там просто отсутствовать. Или быть кривой и в момент ресайза картинки мы вместо пути к файлу получили что-то не то (null или там пустоту - не суть). И там, где я раньше писал "если элемент массива не пуст, то" - теперь надо делать какую-то огромную КУЧУ приседаний, просто чтобы код внезапно не умирал с концами.
Мало того, что не удобно и раздражает - так оно еще и дико многословно получается. Т.е. там, где была 1 сточка длиной в 10-15 символов - теперь это 5-6 строк, которые в ширину даже на экран не всегда влезают (потому что элементы массивов - строковые и длинные).
Всё это дополнительно посыпано "удобствами" в текстовых редакторах, которые до сих пор с трудом с php работают - особенно, если сравнить с тем же c#.
Проблема в том, что Битрикс переходит на "новое" ядро с объектами уже скоро 11ый год как. И до сих пор старое апи работает лучше, а использовать его удобнее и код получается короче и нагляднее. Ну и объекты не спасут вас от бесконечных проверок на null, тогда как в "устаревшем" php я мог сознательно написать if($a=="") и было пофик что там внутри $a - строка, число, null или вообще объект. А сегодня код падает даже на банальном count($a) потому что переменная, внезапно, not countable - потому что где-то в недрах ядра cms что-то пошло не так и оттуда прилетела какая-то фигня. Не то чтобы я прям призывал именно так кодить... Но на фоне строгой типизации в других языках это было удобно - особенно в контексте постоянной работы со строками и непредсказуемыми данными (потому что php для этого и создан). Имхо, сейчас разработчики просто убивают все те преимущества языка, которые и сделали его популярным.
Проблема локального исполнения нейронок не в скорости математики, а в скорости доступа к памяти. И у видюхи эта скорость на несколько порядков выше, чем у десктопного проца с его двухканальным режимом. Поэтому добавление туда NPU проблему с производительностью особо не решает.
Как же они достали уже обратную совместимость ломать. Причём её даже настройками вернуть нельзя. Не, я, конечно, рад, что теперь у меня постоянно есть новая работа. Но я уже немного замучался переписывать лаконичные сравнения с пустотой, на портянки проверок на наличие массива, индекса в массиве, массива в элементе родительского массива и наличии индекса в подмассиве (повторить несколько раз для каждого уровня вложенности). Причём все эти приседания от кода не зависят, так как данные выдаёт Битрикс и там может быть что угодно.
Напомню, что уже с пару месяцев как отказаться от обновлений софта, установленного из виндового магазина больше нельзя. МС теперь их ставит автоматически. Так что отказаться от обновления uwp версии не получится.
Они до перехода на uwp не смогли даже иконку в трее винды сделать! После перехода проблема отпала, так как приложение стало само по себе работать в фоне - особенность платформы. Ну то есть это тоже не заслуга разработчиков вотсапа.
Я ими не так чтобы много пользовался и не могу адекватно сравнить. Но, по ощущениям, вин11 до сих пор работает так, будто это альфа-версия (даже не бета!), где постоянно что-то сломано или недоделано. Причем даже это они постоянно ухудшают)
Если говорить про локальные модели, то очень сильно влияет наличие режима thinking и размер квантования модели. Я на Mistral q4_k_m экспериментировал и её по сюжету рассказа при генерации текста надо было чуть ли не за руку вести, иногда буквально по одному предложению, вместо большого куска текста. И даже так она постоянно путалась и выдавала фигню. Когда я её поменял на Magistral q4_k_m от того же разработчика, но уже с режимом думания - она стала проглатывать весь сюжет за один раз, даже сложный. Её всё равно периодически заклинивало, но разница в качестве была прям на порядки. Ради эксперимента решил попробовать q6 квантование - так она перестала заклинивать там, где q4-версию стабильно клинило. Скорее всего, если использовать q8 или q16 - станет еще лучше. А там же еще и fp16 версии есть с уже совсем негуманными требованиями к ресурсам...
Я тут на днях актуальную вин 11 поставил и настраиваю. Так там сходу из коробки в процессах висит 12 штук msedgewebview2 сжирая 400-600 мб оперативки. 6 штук - это бесполезные виджеты, а еще 6 - это какой-то кусок от поиска. Теперь к ним еще вотсап на хромиуме добавится. Считай - минус гиг оперативки просто постоянно, навсегда. Круто же!
Для меня главным преимуществом радио была неожиданность. То есть там в любой момент могли поставить какую-то песню, о существовании которой я не просто не знал, но даже и искать такое не планировал. И вот когда от радио я отказался (появился безлимитный интернет и все такое), то я столкнулся с тем, что больше не могу найти что-то интересное-новое. Потому что везде все пытаются мне совать а рекомендациях старое и/или похожее. А неожиданного там нет.
Когда вышла вин10 для вин8 внезапно перестали выпускать обновления драйвера видео от амд. Причем для вин 7 драйвер обновляли, а для 8 - нет. И вот ты хочешь поиграться - а игра проверяет версию драйвера и отказывается даже запускаться.
Ну да. В идеальном мире, в больших проектах. А если это типичный "магазинчик на Битриксе", то там иногда даже постоянных разработчиков нет. Просто раз в полгода-год кого-то находят, он реализует накопившиеся желания клиента (чаще всего - максимально через одно место) и на этом про код все опять забывают.
Естественно, что в один "прекрасный" момент клиент решает обновиться - его же Битрикс предупреждает постоянно, что пора. Переключает версию php, нормально обновляется - он же в админке, там всё хорошо. И тут-то и наступает ж... - потому что публичная часть уже перестала нормально работать, а откатывать обновления Битрикс не умеет до сих пор (молодой же проект, всего 20 лет ему!). Бэкапов тоже обычно нет как класса.
И вот тут прихожу я - буквально к руинам...
Ага. Старый код переставал работать при переходе
5.4 -> 5.6
5.6 -> 7.0
7.1 -> 7.2
7.2 -> 7.3
7.3 -> 8.0
8.0 -> 8.2
Тут уже буквально можно на пальцах одной руки посчитать те версии, которые не ломали старый код :)
Если люди хотят писать некачественный код - они будут это делать на любом языке несмотря на любые ограничения. Ладно бы php/js были бы компилируемыми - сделал раз и оно будет работать всегда...
Это печально все-таки. Ну я понимаю что прогресс и всё такое. Но как-то всё-таки хотелось бы иметь соотв. настройки, чтобы совместимость не ломалась бы. Потому что даже в C++ проблемы, если взять код, которому лет 10-20 и попытаться его собрать на свежей версии компилятора.
Стоп. Этот плохой код написал не я. И написан он был очень давно - 5, иногда даже 10 лет назад. Еще во времена php 5.4-5.6 или 7.х. И в то время этот код был полностью в рамках той версии языка.
А теперь это всё, внезапно, разработчики языка просто взяли и сломали - причем даже не оставив возможности как-то вернуть "как было" хотя бы даже и на время.
Вы никогда не правили огромный старый код (который вы раньше даже в глаза не видели!) в режиме ошпаренной кошки и когда "надо еще вчера"? Попробуйте, просто незабываемые ощущения.
Можно, да. Но тогда надо или полностью всё самому писать - или брать какой-то фреймворк. Но лет через 10 вы всё равно придёте к тому же самому - "чтобы обновить на новый php надо переписать вообще всё".
И потом к вам прилетит очередная вирусня и будет ещё хуже.
Ну так проблема не в том, что "сдуру", а в том, что никакого контроля за тем, что выдаст cms у нас нет. Сегодня там одно, завтра они что-то поменяли, мы битрикс обновили и сайт лёг - причем иногда вообще весь.
Обновляемся не от хорошей жизни, а потому что Битрикс обновлять надо. А его обновлять надо, потому что уязвимости + он безальтернативно теперь требует конкретные версии php и выбора, что ставить, уже по сути и нет.
Потому что это Битрикс. Потому что там ВЕСЬ код вот так писался уже лет двадцать подряд - то есть у нас огромная куча унаследованного кода, который физически невозможно корректно переделать. Вы вообще объемы представляете? Базовая установка магазина на Битриксе - это 80 ТЫСЯЧ файлов. Плюс ещё сам шаблон сайта - это тоже несколько сотен, если не тысяча файлов, равномерно размазанных по всему диску.
И когда после обновления сайт ложится (весь или частично), то ко мне прибегает очередной клиент с криками "всё пропало!!!" и надо это вот как-то чинить, причем срочно. А там, бонусом, поверх битрикса еще какой-нить шаблон могли накатить, типа Аспро (а он сам по себе размерами как ещё один Битрикс), который потом несколько лет дописывали сами - и его теперь невозможно обновить, потому что вообще никто уже не помнит и не знает что там и где в нём дописывалось. И там старый код, который падает просто везде - в самых неожиданных местах. Причем одна страница товара работает нормально, а другая - падает, потому что там картинки нет. Или какое-то поле не заполнено было - причем необязательное.
И таких сайтов, замечу - большинство. Не, ну может где-то и есть нормальные - но такие ко мне не приходят, приходят вот эти.
Разработчики php теперь умные и теперь грохают всё сразу, а не как раньше - "пищит, но работает".
Ну я ж говорю - это всё замечательно, пока вы работаете с php так же, как вы работаете в других языках, типа того же С#. Т.е. полноценная среда разработки, отладчик и всё такое.
По факту же, как-то так выходит, что когда мы работаем с cms типа того же Битрикса - там не то что про отладчик речи не идет, там даже полноценное автодополнение кода не работает обычно. И про все крутые фичи работы с классами в IDE можно тоже смело забыть. И вообще замечательно, если хотя бы ftp есть, а не приходится файлы править во встроенном редакторе...
Ну т.е. это всё по удобству получается где-то на уровне как если код в Notepad++ править. Подсветка синтаксиса есть, что-то из текущего файла в автодополнении иногда работает - и это всё.
И когда на вот это вот всё притягиваются ещё и классы и, не дай боги, работа с orm - это просто больно. Потому что кодить это приходится вообще на ощупь. И отладчик не подключить - его нет, он выключен. И даже банальный print_r в Битриксе раньше выкидывал хоть и большой массив, но его хотя бы можно было глазами прочитать - а теперь он выкидывает дамп объекта, у которого часть полей рекурсивно ссылаются сами на себя, а часть требуют геттеров-сеттеров, причем неизвестно каких (потому что даже в документации ничего нет - Битрикс вообще очень не любит обновлять свою документацию). И еще он тебе вываливает портянку мегабайт на 30 чистого текста, от которой даже браузер на мощном компе офигевает. У-удобство.
Что касается вашего примера, то сломать его легко и просто:
Просто, в отличие от "полноценных" приложений на том же c# - мы, в общем случае, в принципе никак не контролируем, что там к нам в код прилетает. Особенно когда у нас это всё завёрнуто в большую cms.
И там, где раньше php был толерантным к кривым данным и просто работал, теперь необходимо делать кучу проверок. И это, ну, неудобно. Потому что, они, ну, не очень-то и нужны - за правильность данных отвечает сама cms, там точно ничего страшного не прилетит. А если тип будет не тот, то php сам автоматом это сконвертирует туда-сюда правильно в большинстве случаев - ну т.е. конвертировал. А теперь надо делать это тоже самому, вручную.
Неа. На практике теперь в php 8.1+ оно чаще всего просто падает с ошибкой обращения к несуществующему элементу массива. Причем, так как у нас много уровней вложенности - то проверять на существование теперь надо их все. И нельзя просто так проверить только самый последний в цепочке даже через какой-нить isset() или empty() - потому что оно тоже падает, если на предыдущем уровне нужного элемента массива тоже нет.
Поверх всего это ещё висит вечная ошибка с "Warning: count(): Parameter must be an array or an object that implements Countable" которая напрочь блокирует любой старый код (все версии php ранее 8.1), где в условиях писали что-то типа if(count($a) && ...);.
Самую мякотку сюда добавляет еще и уникально-php-шная работа функций empty() и isset(), которые возвращают разные результаты в зависимости от того, что там внутри переменной - значение, объект, null или явно заданное false. И это тоже надо перепроверять доп. условием, иначе count() после isset() опять-таки может уронить всю страницу сайта...
В общем, я это всё к тому, что в текущем виде получилась как-то неудобная фигня. И определенно нужен какой-то особый синтаксический сахар вводить, чтобы это всё было как-то более удобно писать в коде.
Я согласен с тем, что для сложных систем и ООП, и строгая типизация - нужны. Проблема в том, что в значительном количестве мест, где сейчас используется php, это всё просто не нужно. Вообще не нужно. Там, иногда, даже код на функции разбивать - уже избыточно.
Ну и у Wordpress'а те же самые проблемы, что и у Битрикса - всё те же постоянные приседания вокруг null и типов.
Просто потому что php работает с внешними данными, которые вообще неизвестно откуда и как в этот код прилетели. И там может быть что угодно - числа, строки, массивы, объекты, base64, json. И в огромном количестве случаев всё это просто пролетает через код дальше - туда, где оно и будет реально обработано и проверено перед выводом (чтобы всякие CSRF-ошибки не словить).
И без строгой типизации все это довольно красиво программилось. А теперь каждое обращение к любым данным надо огораживать заборчиком из кучи условий и проверок.
Вот конкретно в Битриксе, раньше я мог тупо проверить факт наличия пути к картинке и вывести тег img. А теперь мне надо проверить, что массив - это массив, что он не пуст. Что в нем есть соотв. индекс. Что по этому индексу лежит не пустой массив. И только потом я смогу эту несчастную картинку вывести. А всё потому что картинка эта лежит на третьем-четвертом уровне вложенности в массиве. И может там просто отсутствовать. Или быть кривой и в момент ресайза картинки мы вместо пути к файлу получили что-то не то (null или там пустоту - не суть). И там, где я раньше писал "если элемент массива не пуст, то" - теперь надо делать какую-то огромную КУЧУ приседаний, просто чтобы код внезапно не умирал с концами.
Мало того, что не удобно и раздражает - так оно еще и дико многословно получается. Т.е. там, где была 1 сточка длиной в 10-15 символов - теперь это 5-6 строк, которые в ширину даже на экран не всегда влезают (потому что элементы массивов - строковые и длинные).
Всё это дополнительно посыпано "удобствами" в текстовых редакторах, которые до сих пор с трудом с php работают - особенно, если сравнить с тем же c#.
Проблема в том, что Битрикс переходит на "новое" ядро с объектами уже скоро 11ый год как. И до сих пор старое апи работает лучше, а использовать его удобнее и код получается короче и нагляднее.
Ну и объекты не спасут вас от бесконечных проверок на null, тогда как в "устаревшем" php я мог сознательно написать if($a=="") и было пофик что там внутри $a - строка, число, null или вообще объект.
А сегодня код падает даже на банальном count($a) потому что переменная, внезапно, not countable - потому что где-то в недрах ядра cms что-то пошло не так и оттуда прилетела какая-то фигня.
Не то чтобы я прям призывал именно так кодить... Но на фоне строгой типизации в других языках это было удобно - особенно в контексте постоянной работы со строками и непредсказуемыми данными (потому что php для этого и создан).
Имхо, сейчас разработчики просто убивают все те преимущества языка, которые и сделали его популярным.
Проблема локального исполнения нейронок не в скорости математики, а в скорости доступа к памяти. И у видюхи эта скорость на несколько порядков выше, чем у десктопного проца с его двухканальным режимом. Поэтому добавление туда NPU проблему с производительностью особо не решает.
Как же они достали уже обратную совместимость ломать. Причём её даже настройками вернуть нельзя.
Не, я, конечно, рад, что теперь у меня постоянно есть новая работа. Но я уже немного замучался переписывать лаконичные сравнения с пустотой, на портянки проверок на наличие массива, индекса в массиве, массива в элементе родительского массива и наличии индекса в подмассиве (повторить несколько раз для каждого уровня вложенности). Причём все эти приседания от кода не зависят, так как данные выдаёт Битрикс и там может быть что угодно.
Напомню, что уже с пару месяцев как отказаться от обновлений софта, установленного из виндового магазина больше нельзя. МС теперь их ставит автоматически. Так что отказаться от обновления uwp версии не получится.
Нет, ну почему же - вот оно, вы прямо на это вайб-приложение и смотрите /s
Они до перехода на uwp не смогли даже иконку в трее винды сделать! После перехода проблема отпала, так как приложение стало само по себе работать в фоне - особенность платформы. Ну то есть это тоже не заслуга разработчиков вотсапа.
Я ими не так чтобы много пользовался и не могу адекватно сравнить. Но, по ощущениям, вин11 до сих пор работает так, будто это альфа-версия (даже не бета!), где постоянно что-то сломано или недоделано. Причем даже это они постоянно ухудшают)
Они очень стараются - за пять прошедших лет с момента выхода вин11 каждое новое обновление только делает ее еще хуже.
А еще можно просто молча бесконечно крутить индикатор процесса - при этом ничего не делая и генерируя даже логов...
Если говорить про локальные модели, то очень сильно влияет наличие режима thinking и размер квантования модели.
Я на Mistral q4_k_m экспериментировал и её по сюжету рассказа при генерации текста надо было чуть ли не за руку вести, иногда буквально по одному предложению, вместо большого куска текста. И даже так она постоянно путалась и выдавала фигню.
Когда я её поменял на Magistral q4_k_m от того же разработчика, но уже с режимом думания - она стала проглатывать весь сюжет за один раз, даже сложный. Её всё равно периодически заклинивало, но разница в качестве была прям на порядки.
Ради эксперимента решил попробовать q6 квантование - так она перестала заклинивать там, где q4-версию стабильно клинило. Скорее всего, если использовать q8 или q16 - станет еще лучше. А там же еще и fp16 версии есть с уже совсем негуманными требованиями к ресурсам...
Я тут на днях актуальную вин 11 поставил и настраиваю. Так там сходу из коробки в процессах висит 12 штук msedgewebview2 сжирая 400-600 мб оперативки. 6 штук - это бесполезные виджеты, а еще 6 - это какой-то кусок от поиска. Теперь к ним еще вотсап на хромиуме добавится.
Считай - минус гиг оперативки просто постоянно, навсегда. Круто же!
Это вы просто не видели, что там внутри кода сайтов творится - причем массово. Им банально страшно деньги давать!
Для меня главным преимуществом радио была неожиданность. То есть там в любой момент могли поставить какую-то песню, о существовании которой я не просто не знал, но даже и искать такое не планировал.
И вот когда от радио я отказался (появился безлимитный интернет и все такое), то я столкнулся с тем, что больше не могу найти что-то интересное-новое. Потому что везде все пытаются мне совать а рекомендациях старое и/или похожее. А неожиданного там нет.
Когда вышла вин10 для вин8 внезапно перестали выпускать обновления драйвера видео от амд. Причем для вин 7 драйвер обновляли, а для 8 - нет. И вот ты хочешь поиграться - а игра проверяет версию драйвера и отказывается даже запускаться.