О! Что можно сделать? Ну тут многое зависит от конкретного приложения (библиотеки), уровня разработки и опыта самого разработчика, требуемого уровня надёжности и применяемых стандартов выхода из критических ситуаций.
В простых приложениях, безусловно - достаточно просто грамотно упасть (в ггенерацией правильной ошибки, и, если предусмотрено, логированием, в библиотеках ещё и выходить нельзя - там много определяется контрактами этих библиотек - но в простейшем случае это просто должна генерироваться ошибка/исключение "Out of memoery" - а там уже пусть внешний код разбирается - где, в простейшем виде хотя бы где-то в недрах условной точки вхожа функции "main" - всё должно быть огорожено попыткой и последующей обработкой ключевых исключений, приводящих к краху приложения (например, это позволит хотя бы закрыть открытые ресурсы)
В чуть более сложных, особенно многопоточных, приложениях можно подойти к проблеме чуть комплекснее.
Нехватка памяти - это не частое явление под современными ОС (с их файлами подкачки и хитрыми менеджерами памяти; но, например, не всегда включены файлы подкачки (Или кончится место на диске), в ряде случаев могут быть и хуки на процессы, для внешнего контроля за памятью, могут быть и другие случаи; например, 32битные приложения априори не могут обычным путём выделять более 2Гб памяти) - так что задумываться об этом всё-таки нужно. Так что может делать более сложное чем "тривиальное" приложение (кроме как записать логи, выполнить дам памяти, отправить оповещение):
Заблаговременно контролировать нехватку памяти. Конечно, не при каждом выделении, но хотя бы с какой-то периодичностью, и при выделении больших объёмов (в т.ч. неявных, т.е. выполняемых косвенно "чужим" кодом. Причём - чем свободной памяти становится меньше - тем чаще контролировать. Сами критерии, само собой, индивидуальны.
Когда памяти становится слишком мало - можно входить в какие-то особые режимы работы приложения - где проверок будет больше, "лишний" расход памяти будет существенно занижен. Обычно приложения тут информируют пользователя о такой ситуации и начинают работать куда менее производительно
При нехватке памяти приложение должно сократить объёмы кеширования. И вообще очистить все имеющиеся кеш-данных (ну кроме самых критических, если такие выделены оидельно)
Приложение может иметь специальную секцию кода и данных для проведения ревизии выделенной памяти - чтобы оценить объёмы утечек - если их много - то имеет смысл перезапуститься.
Так же, такая ревизия может просто выгрузить какие-то объёмные данные - к которым давно не было обращений (само собой - такая возможность заранее должна быть предусмотрена).
Серьёзное приложение должно либо иметь свой менеджер памяти, либо запускаться в нескольких процессах - с возможностью относительно безболезненно гасить некоторые процессы (выгружая ценные данные их них) - и перезапуская процесс!
При невозможности плавного рестарта по частям - приложение должно перейти в стадию безопасного режима с ограниченной функциональностью - чтобы пользователи (или автоматические алгоритмы) смогли выполнить операции для сохранения рабочих данных перед крахом приложения. При этом, по возможности, надо освободить память от всех остальных объектов.
При выполнении каких-либо критических операций так же можно заранее создавать специальный буфер выделенной памяти - и, если памяти вдруг будет не хватать:
8.1 Если есть свой менеджер памяти - то выделять память можно в этом буфере
8.2. Можно освободить этот резервный буфер и, если возможно, послать менеджеру памяти команду на реструктуризацию памяти
8.3. Можно заранее создать и целый процесс, который выделит большой объём резервной память - а потом просто прибить его - системный менеджер памяти сразу начнёт реструктуризацию памяти
Ну это на вскидку я набросал. Системные программисты наверняка бы предложили ещё что-то.
Да, я говорю "системные программисты" - потому что такого рода задачи - это явно уже не прикладной уровень! Поэтому по хорошему всё управление памяти в серьёзных приложениях нужно выносить на уровень специализированных библиотек! Так же как и управление обработкой исключений (особенно не прикладных).
А вообще - моё мнение такое - что это вообще не задачи программистов конечного ПО, включая рядовые библиотеки! В современном мире программной разработки этим должна заниматься платформа, на которой ведётся разработка, вместе с компилятором/оптимизатором - хотя бы на уровне разработки прикладного ПО. То есть, прикладной программист никогда не должен напрямую вызывать функцию а-ля "malloc" - он должен выделять память через "управляемый" API - который уже сам позаботится о корректной обработке выделения памяти. И через "тот же" API программист заранее должен настроить все, важные, ему нюансы обработки проблемных ситуаций - как на них реагировать. А этот "управляемый" API будет уже обеспечивать выполнение вышеописанных пунктов, при незначительном снижении производительности - а где она особенно критично - так писать код в особых обрамлённых секциях - где лишние проверки будут отключены, но память будет более жёстко контролироваться заранее - до входа в такую секцию - и если оценка даст высокий риск проблем - то попытаться их решить до входа в секцию и при невозможности - не входить в неё - осуществив "отказ в сервисе", и выполнив переход какое-то другое кризисное состояние.
P.S.
Само собой, все пункты выше должны быть реализованы с особо тщательным контролем своей работы и выделения памяти! Как минимум постараться использовать уже созданные заранее объекты, сначала постараться легко очистить доступную для этого память, а потом уже выделять новую под свою работу. Код тут может больше стараться выделять память на стеке, чем в куче. Но и на стеке память, тоже кончается (и порой даже чаще, чем в куче) - но это уже другая тема - и тут свои способы решения чтобы жёстко не упасть!
Хотелось бы посмотреть на правильную проверку выделения памяти в достаточно "среднем" коде где всего-то будет пара тысяч инструкций выделения памяти (не важно - в одном функции или с разнесением по сотням функций (большая часть которых, скорее всего, будут инлайновыми но это не суть). Во что превратится такой код?
А, ну понятно, что опытный программист просто напишет свою глобальную функцию или макрос для выделения памяти и проверки - и будет выделять в одну строчку - но в статье об этом ни слова
Ну так бы сразу и говорили (впрочем, Вы так сразу и сказали - это я ступил). Ну на C# это уже пробовали эмулировать на record - но решение "такое себе" (наверное потому, что не использован ни генераторы, ни расширение компилятора Roslyn и всей ".net compiler platform sdk", включая надстройку для IDE; там в комментариях есть ссылка на другую разработку на generic types , и с применением генераторов; со стороны C# не хватает только анонимных типов в определениях, без создания экземпляров). Вопрос больше - а нафига вообще это в современном ООП, и в C# в частности? в F# это есть потому что это идёт от корней функционального программирования без ООП. В продвинутом ООП в этом нет большой надобности - тут есть классы, интерфейсы и наследования! Ну да - есть решения в некоторых ОО-ЯП, например в Scala - но это больше для галочки более глубокой поддержки функциональной парадигмы (у него была когда-то реализация и под .NET, а так под .NET был ещё Nemerle).
А в C# тут многое упирается в поддержку со стороны платформы .NET - но да, как-то же это сделали для F# (скорее всего опять же через классы и наследования, т.е. не для типов-значений - тут есть ограничения со стороны платформы)
Впрочем, если говорить об объединённых типах - то про желание иметь таковые в C# речь уже шла в обсуждениях развития данного ЯП - но пока воз и ныне там!
В C# класс - это не совсем синтаксический контейнер - это основная типообразующая сущность (вместе со структурой и интерфейсом, и кортежем), даже делегат - это тоже класс. Если не ошибаюсь, кроме классов типы образует только перечисление enum - вроде как классом не являющееся (на уровне платформы .NET), но... я наверное ошибаюсь - вроде там тоже можно и свойства вводить и методы - значит тоже класс! Это упрощает модель типов в C# (и в .NET)
В C# сейчас можно создавать проект без классов - с одними функциями - но это хорошо только для мелких примеров. На практике вряд ли кто-то этим активно пользуется.
Есть же статические функции и свойства!
В C# куда полезнее методика расширений классов дополнительными функциями - это стиль ООП!
А оператор usnig позволяет эффективно создавать псевдонимы длинным именам типов и вообще импортировать статические члены в текущий контекст - буду доступны а-ля глобальные функции и свойства! Чего Вам ещё нужно? (ну, может, наследования статических членов)
C# изначально заточен под ООП и потихоньку впитывает в себя функциональную парадигму.
А вот чего не хватает - это функций высшего порядка - лет 10 назад шли о них разговоры, года 3-4 назад даже "обещали" добавить - но их до сих пор нет. Конечно в C# есть делегаты - но они слишком тяжеловесны и неповоротливы - но, с учётом встроенной библиотеки стандартных типов, вполне себе позволяют программировать и без функций высшего порядка, тем более что поддержка анонимах функций и лямбда-синтаксис имеются!
В этом плане - ОО-ЯП Kotlin куда более перспективен в плане синтаксиса. Ему только не хватает поддержки мощи платформы .NET
Зато, в Kotlin есть мощь легковесных корутин для асинхронного программирования - вроде бы они позволяют создавать ещё более легковесный асинхронный код - чем async\await модель C#
В прочем в C# с асинхронностью всё не так уж плохо!
А ещё в C# есть LINQ - вот это вещь! Как раз построено на методике расширений!
Вот бы ещё макросы и макрофункции... и захват Unit-блока кода как в Kotlin, и инфиксные операторы...
Но скорее нужен просто Kotlin for Dot NET - и я его, кстати, сам разрабатываю...
APU Ryzen 7 8700G c RADEON 780m - это, может и не шибко быстрая графика, но всё-таки это уже RDNA 3 (а не какая-то устаревшая Vega) - и в ней FidelityFX может ещё очень даже проявить себя. Но... да - это всё скорее для ноутбуков будет интересно, ну или на десктопах тем, кто вовсе не планировал пока покупать дискретную 3D видеокарту
Но вообще будем ждать (вероятно как раз через год) 9000 серию APU на ZEN5 с RDNA 3.5 - это, возможно уже преддверие новых игровых консолей (которые навряд ли буду выпускать на чём-то меньшем чем RDNA 4 - но сначала надо десктопных APU отработать) - вероятно это будут PRO версии консолей (SLIM на RDNA 3 и ZEN 4 как раз выпустят, ну или вовсе не выпустят, но PRO уже точно назрели, с технологией FidelityFX версии 4.0 уже как минимум - как разработают)
Процессора ещё нет, когда будет неизвестно - но вы пока берите старье - в стране то ничего больше вообще нет - вот и весь посыл статьи
Если бы хотя бы тесты привели бы (не картинки из чужой презентаций, а реальные сборки) - и показали - вот это вот даёт столько-то FPS и стоит столько-то денег, вот это соответственно столько-то, ну а ожидаемый прирост будет такой-то (и тут же обоснование того как, например презентовали текущее актуальное поколение - и как потом вышло на самом деле - что всё в реальности куда прозаичнее). Тем более, что и процы на DDR5 уже давно в продаже - легко сравнить то, насколько эта памямять на встроенной графике даёт преимущество (или не даёт - ведь там ещё столько нюансов с разгоном) и как в этлм помогает то или иное охлаждение. Вот была бы практическая статья. А так.... одно бла бла бла - причём одно и то же по несколько раз слегка перефразированными словами!
Обработанная передняя часть столешницы мне ни о чём не говорит - вполне классическая форма. Вот только зачем Вам второй уровень на столе - осталось загадкой - судя по фото - совершенно не функционально
Ну а позиции как "сидеть" каждый подбирает для себя сам - Вы же можете просто купить отдельную подставку для ног! Вроде как встроенная в другой вариант данного кресла больше годится для варианта работы с ноутбуком "в руках" (хотя тут тоже лучше тогда и специальный держатель для ноутбука в кресле иметь) - тогда можно удобно работать полулёжа - вот только с внешней мышкой буду проблемы - хотя специальный держатель для её площадки тоже можно установить на кресло
Лично я, наоборот, сторонник приподнятого прямого положения (близкого к 90град) за столом, и локти держу на столе, а мониторы не очень далеко от глаз. Из-за чего мне нужно и мониторы повыше поднимать
Ну я здесь уже предложил это, хотя со мной не согласились, но я спорить не стал (но это, конечно в сравнении с аб. платной на уровне130 руб/мес), если сравнивать с аб. платой на уровне нескольких тысяч - то свой сервер становится очень даже привлекательным - но тут уже узким местом может быть зона трафика: скорость/стабильность/отказоустойчивость провайдера/выделенный IPv4 адрес и т.п. Ну и отказоустойчивость сервера и время восстановления тоже имеют значения. Но всё это важно для прода - но не для "домашних" тестов или каких-то личных сервисов.
Другое дело, когда для тестов:
Либо нужна массовость - сотни и тысячи машин
Кратковременно нужна очень высокая вычислительная мощь
тут как раза такие внешние виртуальные машины очень даже могут быть полезны!
ну $9/год наверняка ещё в чём-то ещё больше будут урезаны: hdd поменьше, процессорное время лимитированное, трафик ограниченный... а ещё может быть целый ворох отдельных доп. услуг - за отдельную плату! Понятно, что кому-то нужно ещё меньше чем предложено здесь!
Респект Вам - смогли запустить всё это в таком объёме памяти. Но видимо поток данных в обработке совсем крохотный (если это не просто стенд для галочки, а "рабочий" инструмент)! Но да - для специфического применения сгодится!
Но если речь идёт о тестах и обучении использования каких-то распределённых серверов и микросервисов или гетерогенных сетевых вычислений - то да, такие хост предложения, позволяющие эффективно управлять десятками и даже тысячами виртуальных машин (соответственно, будучи готовым за это заплатить в месяц от нескольких тысяч до нескольких сот тысяч рублей в месяц - на период проведения особых массовых тестов) - то это да, было бы неплохим решением - вот только ли есть ли у поставщика ресурсы на проведение таких тестов, скажем, на 1000 машин (десяток то другой, кому надо, и дома/в офисе подымет - современное железо это позволит), да ещё чтобы эффективно всеми управлять - опять же желательно через текстовый терминал скриптами?
Например, MS Azure то это без проблем, мог обеспечить!
512мб ОЗУ - всё-таки очень мало.... очень... даже для linux без GUI и контейнеров.
Почти не развернуться - но да за 240 руб в месяц можно получить 1гб ОЗУ - тут хоть как-то поворочиться уже можно. А 512мб - это уж совсем специфические задачи, зачастую проще решаемые домашним выделенным компом (ну когда такой дом есть на территории РФ, но... сейчас такое время что чаще нужен такой хост вне территории РФ, хотя да - релокантам порой нужен клочок родины с доступом из-за бугра - но опять же - если есть где на родине поставить свой комп - который если что будет кому перезагрузить - то это всё-таки более удачное решение, для случаев не требующих высокой оперативности решения проблемы) .
О! Что можно сделать? Ну тут многое зависит от конкретного приложения (библиотеки), уровня разработки и опыта самого разработчика, требуемого уровня надёжности и применяемых стандартов выхода из критических ситуаций.
В простых приложениях, безусловно - достаточно просто грамотно упасть (в ггенерацией правильной ошибки, и, если предусмотрено, логированием, в библиотеках ещё и выходить нельзя - там много определяется контрактами этих библиотек - но в простейшем случае это просто должна генерироваться ошибка/исключение "Out of memoery" - а там уже пусть внешний код разбирается - где, в простейшем виде хотя бы где-то в недрах условной точки вхожа функции "main" - всё должно быть огорожено попыткой и последующей обработкой ключевых исключений, приводящих к краху приложения (например, это позволит хотя бы закрыть открытые ресурсы)
В чуть более сложных, особенно многопоточных, приложениях можно подойти к проблеме чуть комплекснее.
Нехватка памяти - это не частое явление под современными ОС (с их файлами подкачки и хитрыми менеджерами памяти; но, например, не всегда включены файлы подкачки (Или кончится место на диске), в ряде случаев могут быть и хуки на процессы, для внешнего контроля за памятью, могут быть и другие случаи; например, 32битные приложения априори не могут обычным путём выделять более 2Гб памяти) - так что задумываться об этом всё-таки нужно. Так что может делать более сложное чем "тривиальное" приложение (кроме как записать логи, выполнить дам памяти, отправить оповещение):
Заблаговременно контролировать нехватку памяти. Конечно, не при каждом выделении, но хотя бы с какой-то периодичностью, и при выделении больших объёмов (в т.ч. неявных, т.е. выполняемых косвенно "чужим" кодом. Причём - чем свободной памяти становится меньше - тем чаще контролировать. Сами критерии, само собой, индивидуальны.
Когда памяти становится слишком мало - можно входить в какие-то особые режимы работы приложения - где проверок будет больше, "лишний" расход памяти будет существенно занижен. Обычно приложения тут информируют пользователя о такой ситуации и начинают работать куда менее производительно
При нехватке памяти приложение должно сократить объёмы кеширования. И вообще очистить все имеющиеся кеш-данных (ну кроме самых критических, если такие выделены оидельно)
Приложение может иметь специальную секцию кода и данных для проведения ревизии выделенной памяти - чтобы оценить объёмы утечек - если их много - то имеет смысл перезапуститься.
Так же, такая ревизия может просто выгрузить какие-то объёмные данные - к которым давно не было обращений (само собой - такая возможность заранее должна быть предусмотрена).
Серьёзное приложение должно либо иметь свой менеджер памяти, либо запускаться в нескольких процессах - с возможностью относительно безболезненно гасить некоторые процессы (выгружая ценные данные их них) - и перезапуская процесс!
При невозможности плавного рестарта по частям - приложение должно перейти в стадию безопасного режима с ограниченной функциональностью - чтобы пользователи (или автоматические алгоритмы) смогли выполнить операции для сохранения рабочих данных перед крахом приложения. При этом, по возможности, надо освободить память от всех остальных объектов.
При выполнении каких-либо критических операций так же можно заранее создавать специальный буфер выделенной памяти - и, если памяти вдруг будет не хватать:
8.1 Если есть свой менеджер памяти - то выделять память можно в этом буфере
8.2. Можно освободить этот резервный буфер и, если возможно, послать менеджеру памяти команду на реструктуризацию памяти
8.3. Можно заранее создать и целый процесс, который выделит большой объём резервной память - а потом просто прибить его - системный менеджер памяти сразу начнёт реструктуризацию памяти
Ну это на вскидку я набросал. Системные программисты наверняка бы предложили ещё что-то.
Да, я говорю "системные программисты" - потому что такого рода задачи - это явно уже не прикладной уровень! Поэтому по хорошему всё управление памяти в серьёзных приложениях нужно выносить на уровень специализированных библиотек! Так же как и управление обработкой исключений (особенно не прикладных).
А вообще - моё мнение такое - что это вообще не задачи программистов конечного ПО, включая рядовые библиотеки! В современном мире программной разработки этим должна заниматься платформа, на которой ведётся разработка, вместе с компилятором/оптимизатором - хотя бы на уровне разработки прикладного ПО. То есть, прикладной программист никогда не должен напрямую вызывать функцию а-ля "malloc" - он должен выделять память через "управляемый" API - который уже сам позаботится о корректной обработке выделения памяти. И через "тот же" API программист заранее должен настроить все, важные, ему нюансы обработки проблемных ситуаций - как на них реагировать. А этот "управляемый" API будет уже обеспечивать выполнение вышеописанных пунктов, при незначительном снижении производительности - а где она особенно критично - так писать код в особых обрамлённых секциях - где лишние проверки будут отключены, но память будет более жёстко контролироваться заранее - до входа в такую секцию - и если оценка даст высокий риск проблем - то попытаться их решить до входа в секцию и при невозможности - не входить в неё - осуществив "отказ в сервисе", и выполнив переход какое-то другое кризисное состояние.
P.S.
Само собой, все пункты выше должны быть реализованы с особо тщательным контролем своей работы и выделения памяти! Как минимум постараться использовать уже созданные заранее объекты, сначала постараться легко очистить доступную для этого память, а потом уже выделять новую под свою работу. Код тут может больше стараться выделять память на стеке, чем в куче. Но и на стеке память, тоже кончается (и порой даже чаще, чем в куче) - но это уже другая тема - и тут свои способы решения чтобы жёстко не упасть!
Хотелось бы посмотреть на правильную проверку выделения памяти в достаточно "среднем" коде где всего-то будет пара тысяч инструкций выделения памяти (не важно - в одном функции или с разнесением по сотням функций (большая часть которых, скорее всего, будут инлайновыми но это не суть). Во что превратится такой код?
А, ну понятно, что опытный программист просто напишет свою глобальную функцию или макрос для выделения памяти и проверки - и будет выделять в одну строчку - но в статье об этом ни слова
Ну так бы сразу и говорили (впрочем, Вы так сразу и сказали - это я ступил). Ну на C# это уже пробовали эмулировать на record - но решение "такое себе" (наверное потому, что не использован ни генераторы, ни расширение компилятора Roslyn и всей ".net compiler platform sdk", включая надстройку для IDE; там в комментариях есть ссылка на другую разработку на generic types , и с применением генераторов; со стороны C# не хватает только анонимных типов в определениях, без создания экземпляров). Вопрос больше - а нафига вообще это в современном ООП, и в C# в частности? в F# это есть потому что это идёт от корней функционального программирования без ООП. В продвинутом ООП в этом нет большой надобности - тут есть классы, интерфейсы и наследования! Ну да - есть решения в некоторых ОО-ЯП, например в Scala - но это больше для галочки более глубокой поддержки функциональной парадигмы (у него была когда-то реализация и под .NET, а так под .NET был ещё Nemerle).
А в C# тут многое упирается в поддержку со стороны платформы .NET - но да, как-то же это сделали для F# (скорее всего опять же через классы и наследования, т.е. не для типов-значений - тут есть ограничения со стороны платформы)
Впрочем, если говорить об объединённых типах - то про желание иметь таковые в C# речь уже шла в обсуждениях развития данного ЯП - но пока воз и ныне там!
Ну кое что уже есть
на хабре даже заметка была
и эта
ну и тут есть пример
Ну и что бы это такого дало?
В C# класс - это не совсем синтаксический контейнер - это основная типообразующая сущность (вместе со структурой и интерфейсом, и кортежем), даже делегат - это тоже класс. Если не ошибаюсь, кроме классов типы образует только перечисление enum - вроде как классом не являющееся (на уровне платформы .NET), но... я наверное ошибаюсь - вроде там тоже можно и свойства вводить и методы - значит тоже класс! Это упрощает модель типов в C# (и в .NET)
В C# сейчас можно создавать проект без классов - с одними функциями - но это хорошо только для мелких примеров. На практике вряд ли кто-то этим активно пользуется.
Есть же статические функции и свойства!
В C# куда полезнее методика расширений классов дополнительными функциями - это стиль ООП!
А оператор usnig позволяет эффективно создавать псевдонимы длинным именам типов и вообще импортировать статические члены в текущий контекст - буду доступны а-ля глобальные функции и свойства! Чего Вам ещё нужно? (ну, может, наследования статических членов)
C# изначально заточен под ООП и потихоньку впитывает в себя функциональную парадигму.
А вот чего не хватает - это функций высшего порядка - лет 10 назад шли о них разговоры, года 3-4 назад даже "обещали" добавить - но их до сих пор нет. Конечно в C# есть делегаты - но они слишком тяжеловесны и неповоротливы - но, с учётом встроенной библиотеки стандартных типов, вполне себе позволяют программировать и без функций высшего порядка, тем более что поддержка анонимах функций и лямбда-синтаксис имеются!
В этом плане - ОО-ЯП Kotlin куда более перспективен в плане синтаксиса. Ему только не хватает поддержки мощи платформы .NET
Зато, в Kotlin есть мощь легковесных корутин для асинхронного программирования - вроде бы они позволяют создавать ещё более легковесный асинхронный код - чем async\await модель C#
В прочем в C# с асинхронностью всё не так уж плохо!
А ещё в C# есть LINQ - вот это вещь! Как раз построено на методике расширений!
Вот бы ещё макросы и макрофункции... и захват Unit-блока кода как в Kotlin, и инфиксные операторы...
Но скорее нужен просто Kotlin for Dot NET - и я его, кстати, сам разрабатываю...
Судя по пресс-релизу они ещё сами не особо знаю что бы такого развивать в NET 9 - а это печально когда уже первый превью выпускается....
Без кроссплатформенности это всё было не то...
APU Ryzen 7 8700G c RADEON 780m - это, может и не шибко быстрая графика, но всё-таки это уже RDNA 3 (а не какая-то устаревшая Vega) - и в ней FidelityFX может ещё очень даже проявить себя. Но... да - это всё скорее для ноутбуков будет интересно, ну или на десктопах тем, кто вовсе не планировал пока покупать дискретную 3D видеокарту
Но вообще будем ждать (вероятно как раз через год) 9000 серию APU на ZEN5 с RDNA 3.5 - это, возможно уже преддверие новых игровых консолей (которые навряд ли буду выпускать на чём-то меньшем чем RDNA 4 - но сначала надо десктопных APU отработать) - вероятно это будут PRO версии консолей (SLIM на RDNA 3 и ZEN 4 как раз выпустят, ну или вовсе не выпустят, но PRO уже точно назрели, с технологией FidelityFX версии 4.0 уже как минимум - как разработают)
Процессора ещё нет, когда будет неизвестно - но вы пока берите старье - в стране то ничего больше вообще нет - вот и весь посыл статьи
Если бы хотя бы тесты привели бы (не картинки из чужой презентаций, а реальные сборки) - и показали - вот это вот даёт столько-то FPS и стоит столько-то денег, вот это соответственно столько-то, ну а ожидаемый прирост будет такой-то (и тут же обоснование того как, например презентовали текущее актуальное поколение - и как потом вышло на самом деле - что всё в реальности куда прозаичнее). Тем более, что и процы на DDR5 уже давно в продаже - легко сравнить то, насколько эта памямять на встроенной графике даёт преимущество (или не даёт - ведь там ещё столько нюансов с разгоном) и как в этлм помогает то или иное охлаждение. Вот была бы практическая статья. А так.... одно бла бла бла - причём одно и то же по несколько раз слегка перефразированными словами!
Обработанная передняя часть столешницы мне ни о чём не говорит - вполне классическая форма. Вот только зачем Вам второй уровень на столе - осталось загадкой - судя по фото - совершенно не функционально
Ну а позиции как "сидеть" каждый подбирает для себя сам - Вы же можете просто купить отдельную подставку для ног! Вроде как встроенная в другой вариант данного кресла больше годится для варианта работы с ноутбуком "в руках" (хотя тут тоже лучше тогда и специальный держатель для ноутбука в кресле иметь) - тогда можно удобно работать полулёжа - вот только с внешней мышкой буду проблемы - хотя специальный держатель для её площадки тоже можно установить на кресло
Лично я, наоборот, сторонник приподнятого прямого положения (близкого к 90град) за столом, и локти держу на столе, а мониторы не очень далеко от глаз. Из-за чего мне нужно и мониторы повыше поднимать
Ну я здесь уже предложил это, хотя со мной не согласились, но я спорить не стал (но это, конечно в сравнении с аб. платной на уровне130 руб/мес), если сравнивать с аб. платой на уровне нескольких тысяч - то свой сервер становится очень даже привлекательным - но тут уже узким местом может быть зона трафика: скорость/стабильность/отказоустойчивость провайдера/выделенный IPv4 адрес и т.п. Ну и отказоустойчивость сервера и время восстановления тоже имеют значения. Но всё это важно для прода - но не для "домашних" тестов или каких-то личных сервисов.
Другое дело, когда для тестов:
Либо нужна массовость - сотни и тысячи машин
Кратковременно нужна очень высокая вычислительная мощь
тут как раза такие внешние виртуальные машины очень даже могут быть полезны!
Для отдыха?
ну $9/год наверняка ещё в чём-то ещё больше будут урезаны: hdd поменьше, процессорное время лимитированное, трафик ограниченный... а ещё может быть целый ворох отдельных доп. услуг - за отдельную плату! Понятно, что кому-то нужно ещё меньше чем предложено здесь!
Как Вам кресло (вот тоже себе хочу такое)?
Респект Вам - смогли запустить всё это в таком объёме памяти. Но видимо поток данных в обработке совсем крохотный (если это не просто стенд для галочки, а "рабочий" инструмент)! Но да - для специфического применения сгодится!
А для них 512мб ОЗУ не маловато ли будет?
Дома то можно и куда больше позволить.
Но если речь идёт о тестах и обучении использования каких-то распределённых серверов и микросервисов или гетерогенных сетевых вычислений - то да, такие хост предложения, позволяющие эффективно управлять десятками и даже тысячами виртуальных машин (соответственно, будучи готовым за это заплатить в месяц от нескольких тысяч до нескольких сот тысяч рублей в месяц - на период проведения особых массовых тестов) - то это да, было бы неплохим решением - вот только ли есть ли у поставщика ресурсы на проведение таких тестов, скажем, на 1000 машин (десяток то другой, кому надо, и дома/в офисе подымет - современное железо это позволит), да ещё чтобы эффективно всеми управлять - опять же желательно через текстовый терминал скриптами?
Например, MS Azure то это без проблем, мог обеспечить!
Ок, не буду спорить
512мб ОЗУ - всё-таки очень мало.... очень... даже для linux без GUI и контейнеров.
Почти не развернуться - но да за 240 руб в месяц можно получить 1гб ОЗУ - тут хоть как-то поворочиться уже можно. А 512мб - это уж совсем специфические задачи, зачастую проще решаемые домашним выделенным компом (ну когда такой дом есть на территории РФ, но... сейчас такое время что чаще нужен такой хост вне территории РФ, хотя да - релокантам порой нужен клочок родины с доступом из-за бугра - но опять же - если есть где на родине поставить свой комп - который если что будет кому перезагрузить - то это всё-таки более удачное решение, для случаев не требующих высокой оперативности решения проблемы) .
А так хорошо хоть 10Гб на диске есть!
С такими доходами нет никакой мотивации делать HL3
Да, перепутал вселенные. Действительно - это Светлую светлую вселенную там прикончили. Но сути это не меняет. Во славу Его Божественной Тени!