Підтримка Windows 10 незабаром припиниться, і тому Microsoft нещодавно опублікувала нагадування. Технологічний гігант також опублікував список ПК Surface, які не можна оновити до Windows 11, оскільки вони не відповідають системним вимогам. Офіційна позиція компанії проста: придбайте новий пристрій, в ідеалі, Copilot+ PC.
Тим часом домашні користувачі також починають обговорювати, як вони реагуватимуть на цю майбутню зміну. Для тих, хто досі користується системами до 2015 року, які офіційно не можуть запускати Windows 11, багато хто вважає, що Windows 8/8.1, а не Windows 11 чи навіть Windows 10, є кращим варіантом, оскільки стара ОС здається швидше. Читачі Neowin також висловили свої думки з цього приводу. Ви можете долучитися до обговорення в цій статті. Майте на увазі, що хоча це цікава тема для розмови, підтримка Windows 8.1 припинилася ще в січні 2023 року, тому повернення до неї не є безпечним варіантом.
Причиною повільності та млявості системи часто є поганий базовий код, який виконується. Нещодавно з’явилася редакційна стаття під назвою «Недбале програмне забезпечення – причина, чому ви думаєте, що вам потрібне нове обладнання», автором якої є колега Девід Узонду, і схоже, що це Microsoft Працівник цілком погодився б з цією ідеєю, якби прочитав її.
Метт Гемрік, старший інженер з ескалації в Microsoft, опублікував допис у блозі на сайті Microsoft з цього приводу. Тема охоплює витоки пам’яті та проблеми нестачі пам’яті (OOM), з якими може зіткнутися Windows внаслідок поганої оптимізації.
У своїй публікації Гемрік використав приклад оновленого застосунку .NET 7, щоб обґрунтувати ситуацію, пояснюючи, як неправильно розрахований запис ConfigurationBuilder для reloadOnChangeпараметра може призвести до такого результату. Встановивши його значення на “true” замість “false”, застосунок може зіткнутися зі сценаріями витоку пам’яті, що призведе до повільної роботи системи або збою програми, якщо не до збою всієї системи.
Для тих, кому цікаво, цей reloadOnChangeпараметр повідомляє системі про необхідність перегляду вказаного файлу на наявність змінених налаштувань. Це, по суті, допомагає в динамічному перезавантаженні, оскільки автоматично завантажує оновлені налаштування з пам’яті. Таким чином, частини програми, які посилаються на встановлену конфігурацію, можуть одразу побачити нові значення, без необхідності перезавантаження. Отже, саме це призводить до заповнення доступного пулу пам’яті з часом.
Він пояснює:
Вплив цього коду буде тим більшим, чим частіше він виконується. Проблема не очевидна, але ось її причина
reloadOnChange: true:.
reloadOnChange: true… насправді призначений для використання лише під час запуску програми, якщо споживається користувацький файл конфігурації, який сам ASP.NET ще не використовує автоматично (за умови, що ці значення за замовчуванням не були змінені).Натомість, як згадувалося вище, деякі користувачі помилково використовували цей код у чомусь на кшталт дії контролера або компонента проміжного програмного забезпечення, щоб отримати доступ до певного необхідного значення конфігурації, не знаючи, що воно робить «під капотом» (також не знаючи, що конфігурація, яку вони зазвичай шукають, вже завантажена (і відстежується) у систему конфігурації програми).
Метт Гемрік зміг точно визначити проблемний код, спостерігаючи за дампом пам’яті з менеджера пам’яті GC (збирач сміття) .NET за допомогою різних інструментів, таких як WinDbg, утиліта налагодження Windows, та інших.