Комментарии 310
Пользователи ещё не выяснили что каждый элемент windows это плохо оптимизированное приложение на react native?
В принципе, в дизайне windows со времен XP/Nt4 ничего не поменялось, но весь «встроенный» софт тормозит как не в себе.
Так что закрадывается смутное подозрение ….
...что весь интерфейс Windows 11 - это приложение на Электроне?
... что Windows уже не существует, и все что мы видим это web app, запущенный в линухе? нам даже начали давать к нему доступ через WSL!
кто-то случайно нажмет определенное сочетание клавиш, изменится видеорежим и на экране ты увидешь на черном фоне:
Now you are in MS-DOS 11.0 prompt. Type HELP for help.
C:>_
нужно на π кликнуть с зажатым контролом
Открылось окно печати в браузере. ЧЯДНТ?
проверка на олдовость :D
"Сеть"?
На этом расчет и делается корпораций, быстрее разработка - дешевле поддержка.
Пользователя все равно не интересует что там под капотом.
Пользователь все равно не увидит разницы, пока не обновит ПК.
Только в FOSS коммьюнити не забили на оптимизацию и чистоту кода, просто потому что большинство контрибьюторов имеет не особо мощные пк.
Только в FOSS коммьюнити не забили на оптимизацию и чистоту кода,
Только в FOSS коммьюнити не забили на оптимизацию и чистоту кода, просто потому что большинство контрибьюторов имеет не особо мощные пк.
То-то как ни посмотришь в исходники, так кровь из глаз...
Как с хорошо с коммерческими продуктами, исходников не видно и проблемы нет.
+1: https://www.youtube.com/watch?v=nnt5_qWX0eg
Дисклеймер: видео не смотрел, мне нейросеть пересказала суть ;) Там комментарии из непоколебимого качественного энтерпрайза Майкрософт.
Только почему-то Apple с четким видением и длинной палкой сверху обскакала и Windows и настольный Linux в плане оптимизации быстродействия и энергосбережения одним махом с выходом M1.
потому что ПАК с фиксированным набором конфигураций всегда проще оптимизировать, чем систему, которая должна работать на всём подряд от притащенного с помойки говна до стоядерных рабочих станций и серверов
PCI, ACPI, управление питанием процессора P-states/C-states стандартизовано уже XX лет назад. Если Microsoft может легко продавить производителей на TPM 2.0, SSD вместо HDD, Pluton, то и тут бы мог взять всех за уши и наказать исправлять недочеты и дорабатывать прошивки.
PS: Насчет помоек - голословное утверждение, покуда были даже официальные Surface.
А что касается (не ядра) Linux, то у меня lock screen при заснувшем экране заставляет вентиляторами жужжать. Стопудово где-то busy wait.
PCI, ACPI, управление питанием процессора P-states/C-states стандартизовано уже XX лет назад.
Тем не менее оратор выше прав, кроме всего этого есть ещё дохрена других параметров системы, в довесок некоторые из производителей реализуют стандарты по-своему.
покуда были даже официальные Surface.
Это не "ограниченное количество конфигураций", как у Эппл, а "100500 конфигураций + Surface"
А что касается (не ядра) Linux, то у меня lock screen при заснувшем экране заставляет вентиляторами жужжать. Стопудово где-то busy wait.
УМВР, что опять же подтверждает тезис оратора выше. Зоопарк конфигураций -> сложно оптимизировать.
а "100500 конфигураций + Surface"
Это что, HAL на Windows настолько течет, что одному вендору, и по совместительству разработчику ОС, не удается донастроить систему даже под одну заведомо известную конфигурацию?
Но по факту, оно очень даже может (могло, конец 2019г.) уходить в энергосберегающие режимы. Жор всей системы в минимуме:
Core i7 1065G7 = 1.6W
Ryzen 7 3780U = 3W
Зоопарк конфигураций -> сложно оптимизировать.
дохрена других параметров системы
Сложно оптимизировать стандартные настройки, да. Максимум, что может сделать MS для подгонки под устройства: разные "профили" как набор настроек. А доведением до ума и подбором компонентов должен заниматься системный интегратор.
в довесок некоторые из производителей реализуют стандарты по-своему.
То есть не магия Apple, а есть конкретные чипы, компании и лица, которых можно пинать и заключать договора. К чему я и отсылал: у Microsoft хватило менеджерской воли и желания всем пропихнуть TPM 2.0. Осталось бы еще bloat убрать, может и вышла бы долгоиграющая система.
Вот сегодня случайно наткнулся на видео. Lenovo Go S на Windows против SteamOS. В чью пользу разница от 1.25x до 2x по времени работы от аккумулятора? :) Правильно угадаете.
PCI, ACPI, управление питанием процессора P-states/C-states стандартизовано уже XX лет назад.
Расскажите это китайцам. Ну или хотя бы крупным производителям типа того же HP, которые на все эти спецификации кладут давно и надёжно.
Точней, не кладут, не реализуют зачастую весьма и весьма криво, а это влечёт за собой всякие разные проблемы.
Вообще, списки ошибок в железе (так называемые Errata) для сложных микросхем могут содержать сотни страниц; про программные ошибки и говорить нечего -- там зачастую ещё хуже (правда, в отличие от "железных" ошибок, их можно, хотя бы в теории, исправить перепрошивкой BIOS или его аналога на конкретной платформе). Так что Эпл, имея дело с крайне ограниченным кругом железа, находится в заведомо выигрышной позиции по сравнению с Линухом или Виндой -- что, естественно, не отменяет того факта, что означенные системы написаны далеко не так хорошо, как хотелось бы.
Промахнулся комментарием. Неследование стандартам имеет место быть.
М1 опережал процессоры на x86 на два-три поколения техпроцесса. Пока Intel делала на 14 нм там уже было 5нм. На одинаковом техпроцессе и потребление энергии чисто процессором очень сильно сближается. А вот дальше вступает в дело уже описанный рядом фактор того что маки то ПАК, а не безумный зоопарк всего и вся на х86.
А ещё влияние архитектуры. В частности, декодировать команды ARM многократно проще, чем AMD64/Intel64, из-за чего соответствующие железные блоки при прочих равных будут существенно компактнее, а значит, и жрать намного меньше. (Вот потребление и размеры кэшей или там АЛУ от архитектуры уже практически не зависит).
Это правильно, но я считаю этот эффект вторичным. Он проявляется особо остро на вычислительных бенчмарках. В повседневном использовании вижу же уйму проблем из-за неправильно настроенного питания и агрессивного турбо. Потому я и ответил в комментарии ниже ссылаясь на замер idle, где процессор в координации с системой может отключать многие свои подсистемы и периферию, уходя в энергосберегающий режим, где ему не мешают пробуждениями.
Кстати, Microsoft сделала большой шаг в этом направлении исправив пару лет назад давнишний баг недочет с разрешением системного таймера, который многими приложениями (в т.ч. Chromium) устанавливался в 1мс.
Вот конкретное влияние этого эффекта было бы интересно исследовать, а не сравнения в духе M1 на 5нм заметно лучше Intel на 14нм и явно же все дело в том, что "декодировать команды ARM многократно проще ".
Подозреваю оно не такое уж и большое.
Как только начинают делать ARM того же класса производительности что и x86 и на аналогичном техпроцессе то у них и энергопотребление становится очень близким.
Новый техпроцесс 10нм Intel выпустила только под мобильные чипы, как додумывала публика, из-за проблем с yield, которая бы не дала сделать большие настольные и серверные чипы.
i7 1065G7 за год до M1: 10 nm - https://www.anandtech.com/show/15213/the-microsoft-surface-laptop-3-showdown-amd-picasso-vs-intel-ice-lake/6
i9 11980HK как оппонент M1: "10nm SuperFin" - https://www.anandtech.com/show/17024/apple-m1-max-performance-review/3; обновление которого как Enhanced SuperFin потом ребренднули в Intel 7.
Хорошо, техпроцесс выбрали отличный. А почему тогда в idle разница в пять раз: 0.2W против 1.08W? Магия техпроцесса или разница и правильная конфигурация платформы? А твой процессор пребывает в C-State 10?
Далее, для всего устройства: 7.2 против 13.5. Даю подсказку: подвеска в активном состоянии плюс чипсет. Зоопарк заканчивается на процессоре и чипсете. Остальное - задача системного интегратора... дополняется хорошей поддержкой ОС и драйверов. Если что, вот компоненты на iMac 21. Вижу всё те же имена: ASMedia для USB, Intel для TB4 retimer, внешние чипы для аудио, ethernet, wireless.
Я не вижу, чем это отличается от того, что написал я - более совершенный техпроцесс (10нм это все равно не 5нм, даже при всей условности это в лучшем случае аналог 7нм TSMC то есть все равно отставание на поколение, аналогом TSMC 5нм был уже Intel 4) плюс гораздо более тесная интеграция с софтом в рамках ПАК.
Ну и здесь где-то чуть выше например сравнивали М1 именно с 14нм процессором Intel. Наскольок я понимаю ранний 10нм/Intel 7 выпускался в очень ограниченных обьемах.
Какую-то долю наверное вносило то, что Intel всю свою историю делала в основном процессоры с высоким энергопотреблением и опыта по жесткой оптимизации именно энергопотребения при прочих равных у них меньше было, но не думаю, что прямо таки радикальную.
ПАМАГИТЕ
Ну вообще это не такая и новая мысль. В Windows XP Проводник и сам рабочий стол являлись хитро запущенным Internet Explorer. То, что отображалось в самой папке ниже тулбара, к примеру, было веб-страницей. И по этой же причине на фон рабочего стола можно было поставить даже какую-нибудь веб-страницу из интернета.
Именно поэтому, когда давно суды решили, что нельзя поставлять свой браузер вместе с операционной системой потому, что это неконкурентное преимущество, Майкрософт смогли лишь скрыть существование IE в системе и предложить установить альтернативы при первом запуске, а не избавиться от него полностью.
Эээ, вас кто-то обманул. Проводник и рабочий стол работали через explorer.exe, тогда как ie был собсна iexplorer.exe по моему. И это были разные процессы с разными задачами.
Насколько помню попытка открыть интернет адрес в адресной строке проводника открывала отдельно ie, но уже плохо помню.
Хорошо, давайте я раскрою мысль "хитро запущенный IE". Я имею ввиду, что движок Trident, ActiveX, VBScript, JScript использовались повсеместно, в том числе в Explorer, и в Internet Explorer. Что очень похоже на начало разговора об использовании Electron в качестве основы для компонентов Windows 11.
У них были общие компоненты - да. Проводник не являлся хитро запущенным ИЕ.
Проводник делал тоже самое, что и ИЕ и чуть больше. Вы даже сами могли написать веб-страничку и вставить в любую папку как фон. Там даже скрипты крутились точно так же.
Рядом тут писали уже про это. Это всё ещё компоненты общие (activex, webview), а не IE.
ЕМНИП, можно было даже вставить http://* в адресную строку Проводника, и увидеть сайт.
Так же как можно было написать C:\ в адресной строке IE, и получить доступ к файлам, что использовалось для обхода ограничений во всяких компьютерных клубах, где пользователю были доступны для запуска только IE и игры.
Увы, его не обманывали.
про папки https://learn.microsoft.com/en-us/windows/win32/lwef/web-view
про десктоп https://superuser.com/questions/491912/display-webpage-on-desktop-background-winxp
https://ru.wikipedia.org/wiki/Active_Desktop
Причём про фичу Active Desktop я помню что была она до XP. Чуть ли не в 98 можно было html поставить вместо обоев.
Вот это забавно. При этом в висте ещё был ИЕ, но таких возможностей уже не было. И даже не знаю, было это кому-то нужно или просто сделали и оказалось что ерунда.
Я помню про вебвью в проводнике, но мне казалось там специфическое подмножество хтмл было со своим синтаксисом.
А в висте такие возможности и не нужны были. Там все на XAML было, который гораздо более гибкий, чем то что мог предоставить IE/HTML на тот момент. HTML5 со всеми его плюшками тогда только зарождался.
И даже не знаю, было это кому-то нужно или просто сделали и оказалось что ерунда.
Браузер специально сделали неотъемлемой частью операционной системы, чтобы был аргумент в суде, мол ставим IE по умолчанию и не можем удалить его из системы, потому что без него система не работает.
Чуть ли не в 98 можно было html поставить вместо обоев.
Даже в 95 можно было. Но большинство узнали о существовании о нём по Active Desktop recovery из Millenum. :)
В Win98 SE фича с ActiveDesktop была точно.
Чуть ли не в 98 можно было html поставить вместо обоев.
Оно, правда, больше тогда запомнилось не данной возможностью, а голубым треугольником с восклицательным знаком и надписью о том, что Active Desktop упал.
В Windows ME для его появления достаточно было просто перезагрузить компьютер с кнопки Reset.
Основная функциональность IE явно находится (и находилась раньше) в каких-нибудь dll, которыми кроме iexplore.exe может воспользоваться кто-то другой (через явную подгрузку, COM интерфейс или как то ещё).
Эээ, вас кто-то обманул. Проводник и рабочий стол работали через explorer.exe, тогда как ie был собсна iexplorer.exe по моему
Вы путаете c Хромиумом, который тащит 6 процессов. А ишак жил в mshtml.dll (там была ещё пара dll'ек, а подключался он через .ocx) и грузился в адресное пространство внешнего процесса, в данном случае — explorer.exe.
О, вот это интересная информация. За давностью лет про это уже забыл.
Почитал https://en.wikipedia.org/wiki/Trident_(software) чтобы вспомнить про это дело, а потом ещё по ссылке нашел https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa752038(v=vs.85)
И понял что меня с толку сбило - был этот самый mshtml который именно что рисовал что просили, а был WebBrowser Control который мог делать полноценную работу браузера внутри приложений.
Если я всё помню правильно, мы говорим об одном и том же. Этот самый WebBrowser Control, он же Trident, был .ocx'ом (ActiveX-компонентом), но имплементация жила в mshtml.dll.
И да, лет прошло очень много, я тоже пишу по памяти. Но у меня прямо сейчас моё старое приложение висит в процессах, я смотрю, на Win11 оно подгрузило mshtml.dll и ieframe.dll, а те потащили DirectX (потому что я использовал директиксовский CSS filter: progid:DXImageTransform). Дочерние процессы оно точно не породило.
В Windows 98 тоже можно установить фоном рабочего стола интернет-страницу.
Не распространяйте мифы и дезу.
Не открывайте рот
Для адекватных людей, который доберутся до этого места в дереве комментариев, сообщаю, что
В Windows XP Проводник и сам рабочий стол являлись хитро запущенным Internet Explorer. То, что отображалось в самой папке ниже тулбара, к примеру, было веб-страницей.
то, что отображалось в самой папке ниже тулбара, было окном класса SysListView32 — самым обычным контролом из comctl32.dll с самой обычной оконной процедурой (WindowProc), живущей в comctl32.dll и обрабатывающей самые обычные оконные сообщения. При этом окно сабклассилось динамически генерируемым thunk-ом из DUSER.DLL, который делал тривиальную фильтрацию оконных сообщений и через CallWindowProc вызывал оригинальную оконную процедуру из shell32.dll.
Унификация архитектуры проводника и IE в какой-то сфере, поддержка разными COM-классами оттуда и отсюда одного и того же COM-интерфейса, а также одинаковые интерфейсы для создания модулей расширения (например, можно было написать класс, имплементирующий определённый интерфейс, для того, чтобы добавить в IE или Проводник свой кастомный тулбар — и способ создания был одинаковым, что для IE, что для Проводника) не делает одно частью другого, или не делает одно и другое одним и тем же.
Если два разных класса реализуют один и тот же интерфейс, это не значит, что это два одинаковых класса, или первый класс является хитро запущенным вторым классом.
То, что окно проводника при необходимости могло захостить внутри себя IE-контрол из ieframe.dll (не всегда, а только при необходимости), или Internet Explorer мог при необходимости захостить внутри себя shell-овское окно с фаликами, папками или апплетами Панели инструментов — не делает одно частью другого.
С таким же успехом автокадовский документ мог быть встроен в вордовский файл благодаря технологии OLE/ActiveX.
И ведь все это можно было написать не говоря другим людям, что делать
тут мы уже смещаемся в спор, с какого момента одна сущность превращается в другую
Если уж на то пошло то осел, это конструктор с запускалкой в виде iexplorer.exe ...вы же не считаете что iexplorer - это IE? ведь остальные его части это часть самой винды....собранные в одну кучку в окошке с тулбаром и стрелочками вперед-назад-стоп
даже настройки осла, это кусок панели управления винды которые почти неизменно доползли до 10 винды
тут мы уже смещаемся в спор, с какого момента одна сущность превращается в другую
Да нет, спор вполне конкретный.
Было утверждение, что то, что в окне ниже меню с тулбаром, то есть то, что отображает файлики и папочки, это, якобы, веб-страница.
Это чушь и ересь. Веб-страница — это нечто, что написано на HTML и что имеет DOM.
На самом же деле то, что Проводник использует для отображения файлов и папок, это не веб-страница, а нативный pure-WinAPI-style контрол SysListView32 из comctl32.dll
вы же не считаете что iexplorer - это IE?
iexplore это EXE-шник с внешней оболочкой. Ядро в ieframe.dll
Точно так же explorer.exe это по большей части обёртка, а ядро в shell32.dll
При этом shell32.dll и ieframe.dll это не одно и то же. И самое главное, что отображение папок и файлов это не веб-страница, а нативный контрол, получающий оконные сообщения и отрисовывающий себя с помощью GDI.
В технологии Active Desktop использовался трюк с подкладыванием браузерного фрейма под ListView-контрол, который был сделан как бы с прозрачным фоном. Это не делает проводник и ListView-контрол хитро запущенным ишаком.
К сожалению, у вас есть проблемы с пониманием контекста. Кроме того, вы переходите на личности, говорите другим людей что делать, и обижаетесь, когда это говорят вам. Именно поэтому я и обсуждаю вашу личность сейчас, так как вы вместо доказательств стали хамить.
Итак, про контекст: статья говорит о том, что часть операционной системы Windows 11, а конкретно меню Пуск является веб-приложением, это очень неожиданно, видеть веб-технологии там, где их быть не должно.
Другой человек в шутку предполагает, а не написан ли весь интерфейс Windows 11 с помощью Electron? А Электрон -- это такой способ предоставить возможность использовать для интерфейса приложения веб-технологии и, одновременно, получить более глубокий доступ к системе, чем сайт.
Я говорю не совсем точно и поправляясь, что вообще говоря интерфейсы на веб-технологиях рисовали ещё при Windows XP. И, для простоты понимания, называю движок именем браузера. Надо сказать, что именно так и описывают Электрон простыми словами -- ну это такой хром, который хитро обёрнут для того, чтобы создавать десктопные приложения.
Но дальше, вместо того, чтобы уточнить, в чём я конкретно не прав, вы решаете написать, что мне делать и что нет, ещё и в форме, что я не прав ни в чём и всем вру.
Так вот, врёте и вы, только у вас не хватит сил этого признать. И вот почему:
По ссылке из официальной документации https://learn.microsoft.com/en-us/windows/win32/lwef/web-view написано, что проводник имеет два вида отображения Classic View и Web view, притом:
Much like conventional webpages, Web views are controlled by an HTML-based template. Authoring a Web view template is nearly identical to authoring a webpage and provides the same degree of flexibility in content and layout of information. Web view templates can use Dynamic HTML (DHTML) and scripting to respond to events, such as a user clicking an item. They can also host objects that allow them to obtain and display information from the folder or its contents.
То есть это ПРЯМОЕ ОПРОВЕРЖЕНИЕ вашей мысли:
Было утверждение, что то, что в окне ниже меню с тулбаром, то есть то, что отображает файлики и папочки, это, якобы, веб-страница.
Это чушь и ересь. Веб-страница — это нечто, что написано на HTML и что имеет DOM.
Да, это именно ВЕБ-СТРАНИЦА, если использовать режим Web view. Вы или этого не знали, или решили сознательно скрыть. Но то, что не существует способа управлять отображением папочек с помощью веб-шаблона - ЛОЖЬ. В ваших терминах ЧУШЬ И ЕРЕСЬ. Способ есть, а в статье даже приведён пример такого шаблона.
Кроме того, в этой же статье написано прямо:
However, the region that was occupied by the file list becomes a general-purpose display area that is effectively a webpage.
То есть именно то, что я описываю словами:
что отображает файлики и папочки, это, якобы, веб-страница
И даже такая строка там есть:
In a Web view, there is virtually no difference between Internet Explorer and Windows Explorer.
Обратите внимание, ОНИ ТАК ЖЕ ИСПОЛЬЗУЮТ ТЕРМИН Internet Explorer в ОФИЦИАЛЬНОЙ ДОКУМЕНТАЦИИ.
Таким образом, моя ошибка была в том, что я забыл, что это был отдельный режим отображения и можно было включить классическое отображение, которое описываете вы.
Вы же ошибались во всём, касаемо того, можно ли описать через веб-шаблон отображение папки, и кроме того, обвинили меня во лжи, запретили мне писать то, что подтвержается документацией.
Хватит смелости признать ошибку и извиниться?
За что ему извиняться? Человек винду знает идеально, как что устроено, и все по делу сказал.
Изначальное громкое утверждение:
В Windows XP Проводник и сам рабочий стол являлись хитро запущенным Internet Explorer. То, что отображалось в самой папке ниже тулбара, к примеру, было веб-страницей.
Я написал, что ничего подобного.
На что последовало «разоблачение» меня:
Так вот, врёте и вы, только у вас не хватит сил этого признать. И вот почему:
По ссылке из официальной документации https://learn.microsoft.com/en-us/windows/win32/lwef/web-view написано, что проводник имеет два вида отображения Classic View и Web view, притом
...
То есть это ПРЯМОЕ ОПРОВЕРЖЕНИЕ вашей мысли:
Да, это именно ВЕБ-СТРАНИЦА, если использовать режим Web view
Тем временем, по приведённой ссылке:
Не хватило смелости!
А ещё, то, с чем вы спорите, как вы говорите, я поправил за несколько часов до вашей предъявы мне в комментарии: https://habr.com/ru/news/913050/comments/#comment_28358302
Вы его проигнорировали.
Во-вторых, признайте уже, что вы можете не знать всего. Да, та статья относится к старым версиям, но только потому, что это выпилили в СП1, а не потому, что этого никогда не было в Виндоуз ХП: https://ftp.zx.net.nz/pub/Patches/ftp.microsoft.com/MISC/KB/en-us/812/003.HTM#:~:text=The original release of Windows XP continues to support the use of HTML templates (Folder.htt) in Web view from earlier versions of Windows.
Ну и вы до сих пор не поняли, что если это было в версиях до ХП, то это играет мне на руку потому, что смысл моего комментария был в том, что идея не нова.
А ещё, то, с чем вы спорите, как вы говорите, я поправил за несколько часов до вашей предъявы мне в комментарии:
Коммент, к которому была претензия, не правился. И сделанное там громкое заявление нигде ниже уровнем не отменялось, не опровергалось. А только дополнялось новыми мыслями. Точнее там даже не одно спорное заявление, а несколько.
https://habr.com/ru/news/913050/comments/#comment_28358302
Вы его проигнорировали.
Я это видел. Я не проигнорировал, а с трудом удержался увидев перечисление «Trident, ActiveX, VBScript, JScript» не процитировать древний мем из аудиозаписи лекции по информатике:
В настоящее время в сети существует (живут, существуют) большое количество разнообразных злоумышленников: хакеры, крэкеры, спамы, куки, троянские кони.
Оригинал тут
Всё намешано в кучу, но особо выделяется в этом ряду «ActiveX».
Но это дополнение с непонятным перечислением разнородных терминов не опровергает и не переиначивает изначальный посыл, а точнее их было два:
Проводник является хитро запущенным IE под Windows XP.
Под Windows XP отображение содержимого папки, то есть всё, что ниже тулбара является веб-страницей.
Во-первых, мы уже выяснили, что к XP это вообще не имеет отношения.
Во-вторых, если даже взять какую-нибудь Windows 98, где был вот этот режим (как опция, а не единственный вариант существования),а а также был Active Desktop — а они устроены немного по разному — то всё равно содержимое папки не отображалось с помощью веб-страницы.
Это решение уровня:
А давайте мы в окне Проводника вместо контрола SysListView32 положим IE-фрейм, а уже внутри IE-фрейма поместим изначальный SysListView32.
В итоге ради того, чтобы пользователь мог кастомизировать внешний вид папки, сделан опциональный режим, в котором используется промежуточный контейнер (способный отображать HTML-документ ради создания того самого краевого оформления), внутри в центре которого по прежнему лежит нативный контрол.
Вся суть и соль отображения содержимого папки: файлики, папочки, значки, ярлычки, выделение файлов, табличный режим с заголовками и сортировкой при кликах по заголовкам, мелкие значки, крупные значки — всё это:
а) Нативный контрол, тот же самый ListView, какой был бы если бы ради краевого оформления режим промежуточного контейнера не привлекался
б) Не состоит из DOM-элементов и не является поддеревом DOM родительского IE-фрейма (кроме самого контрола FileList — он весь целиком представлен одним единственным DOM-узлом типа <object>).
в) Не подчиняется CSS веб-страницы, в которую он встроен. Ни с помощью CSS нельзя поменять размер или начертание шрифтов в файлов (всех или выборочно), ни с помощью JScript/VBScript из родительского страницы не получится раздвинуть два значка файлов и между ними вставить элемент <marque>, или <div>, или <table> или что угодно HTML-ное.
Отображение самого содержимого папки — не веб-страница, а нативный контрол. Но сделан режим, в котором между родительским окном и нативным контролом промежуточным контейнером выступает IE-фрейм ради возможности создать краевой оформление (то есть не только боковую левую панель, но и что-то сверху, что-то справа, что-то снизу — при желании).
--------------------
C Active Desktop и рабочим столом всё обстоит по другому: если в окне проводника нативный ListView с непрозрачным фоном лежит внутри HTML-документа, то есть один child, а другой parent, то в случае с рабочим столом ListView с прозрачным фоном лежит поверх IE-фрейма, то есть в случае иерхархии окон (тех, у которых есть HWND) они сиблинги.
------------------
Тот факт, что в окне Проводника в определённом режиме работы (то есть при определённых настройках) встроен контрол, который в первую очередь является частью приложения Internet Explorer, не делает проводник хитро запущенным Internet Explorer-ом.
Тем более оно не делает его хитро запущенным Explorer-ом под XP, где такого вообще нет. Но даже в условном Windows 98 — тоже не делает, потому что с тем же успехом автокадовский документ мог быть внедрён (слава технологии OLE, которая просто стандартизирует единый «протокол» для контролов, которые хотят быть внедряемыми, — с одной стороны, и контейнеров, которые хотят в себя что-то внедрять, — с другой) в Excel-документ, а сам Excel-документ мог быть внедрён в Word-документ.
Это же не делает Excel хитро запущенным АвтоКАДом, а Word — хитро запущенной экселькой?
У меня нет установленного АвтоКАДа, но есть установленный Компас, и я легко могу воспроизвести то, о чём говорю:
Раз
Два
Три
Четыре
Пять
Является ли то, что показано на этих 5 скриншотах доказательством того, что:
Excel это просто хитро запущенный Word
Word это всего лишь хитро запущенный Excel
Excel и Word это одно и то же
Компас-3D это всего лишь хитро запущенный Excel
Excel это всего лишь хитро запущенный Компас-3D
Компас-3D является неотъемлемой частью Excel и Word?
Во-вторых, признайте уже, что вы можете не знать всего.
Конечно, могу чего-то не знать. И в этом случае я беру инструменты, такие как тот же Spy++, отладчик, дизассемблер и иду смотреть, как оно устроено, а не перепощиваю мифы и байки.
то это играет мне на руку потому, что смысл моего комментария был в том, что идея не нова.
Какая именно идея? Идея строить UI прикладных приложений используя HTML-документ?
А вот и нет!
Ни в XP, ни в более ранних версиях ОС авторы не использовали HTML-документы и IE-frame для того, чтобы с их помощью реализовать именно интерфейс прикладных приложений.
Можете привести ещё примеры? Единственный известный мне пример использования веб-страницы в рамках других приложений: это HTMLHelp (с .chm-файлами) пришедший на смену Win95 Help (.hlp-файлы) на базе RTF-документов. Но здесь с помощью HTML отображается контент, текст с разметкой, гипертекст (то есть именно то, для чего HTML исходно задуман), а вовсе не интерфейс приложения.
Примеров, чтобы HTML использовался для отображения именно интерфейса приложения, а не контента приложения, я не могу вспомнить.
Ну а в проводнике HTML применён для кастомизации рядовым пользователем своих папок. Хочешь кастомизировать отображение своей папке — тебе не нужно быть программистом, не нужно иметь IDE, не нужно иметь компилятор, не нужно знать глубокое устройство Windows.
Для тебя, как для рядового пользователя, сделали специальный мастер:
То есть по задумке авторов это сделано для того, чтобы любая домохозяйка могла кастомизировать себе внешний вид папки. Ну, не любая, но изучившая HTML и JS. Прямо в проводник для этого встроен пунктик меню, мастер и HTML-открывается прямо в Блокноте.
Electron, хотя я про него почти ничего не знаю, создан не из таких предпосылок. Он не сделан для того, чтобы широкий круг пользователь мог кастомизировать какую-то маленькую часть внутри нативного приложений.
Он сделан таким, каким он сделан, не для того, чтобы кто-то из рядовых пользователей лез что-то модифицировать в чужом приложении, не поднимаясь до уровня разработчика по знаниям. Он таким сделан потому, что разработки деградировали до уровня домохозяек — если не по уровню знаний, то по уровню беззаботности.
Так что это не та же идея.
Я не вижу и не помню ни в XP, ни в более ранних ОС примеров именно интерфейсов на HTML+JS/VBS.
По итогу, в двух провокационных комментах выше высказывалось сразу 3 тезиса:
Прообраз Electron-а был заложен ещё во время Win9x — не правда, потому в прикладных приложениях для реализации UI никто (в Microsoft) не использовал тогда HTML+JS, а в Проводнике это было сделано для кастомизации.
Отображение папки в Windows XP — это веб-страница. Не правда, потому что в XP никаких веб-страниц не использовалось, и даже в более ранних ОС сам контент папки отображался нативным контролом ListView, а веб-страница использовалась только для создания какого-то краевого оформления вокруг этого нативного контрола.
Проводник это хитро запущенный IE. Не правда, потому что модульная архитектура приложений и наличие стандартизированного способа встраивания объектов не делает одно приложение тщательно маскирующимся другим приложением или не делает одно приложение неотъемлемой частью другого.
То, что между разными приложениями в огромной мере есть code reuse за счёт использования одних и тех же DLL, компонентов, реализации одних и тех же COM-интерфейсов — это не ставилось под сомнение. Вам об этом и написали сразу.
что весь интерфейс Windows 11 - это...
в прямом смысле интерфейс IShellFolder от COM-объектов, моникеров, displayname, которые ещё со времён Windows XP/Server 2000 НЕ поменялись от слова СОВСЕМ.
Тоже самое с реестром Windows, базовыми WinAPI, отрисовкой средствами DirectDraw.
Я помню, как они переделали калькулятор - то ли в 7 то ли в 10 винде. И калькулятор, крохотное и примитивнейшее приложение, начал ощутимо тормозить с запуском и отрисовкой - на многоядерном процессоре, SATA SSD и мощной видеокарте он загружался несколько секунд.
Потом у меня еще прибавилось ядер, видеокарта стала еще мощнее, SSD стал nvme pci-e и тормозов больше не замечаю.
Я так понимаю там еще не React был, а UWP, следующая итерация XAML после WPF, и когда-то в древние времена я переводил статью про то как WPF тормозит даже по сравнению с вебом не говоря уже о более древней Windows Forms - Глубокое погружение в систему рендеринга WPF.
И калькулятор, крохотное и примитивнейшее приложение
Он просто перестал быть крохотным и примитивнейшим.
Оно теперь даже курс валют считает в реальном времени.
Этому функционалу нужен 20 ядерный процессор и 50 гигабайт оперативки и обязательно SSD?
Этому функционалу
Не нужны.
Абсолютно не нужно. Но если повырезать из системы то, что некоторые люди считают не нужным или всякие "оптимизации" сделать, то встроенные приложения начинают себя вести неадекватно.
Этому функционалу нужен 20 ядерный процессор и 50 гигабайт оперативки и обязательно SSD?
Конечно да!
/s
В Windows Vista, 7, 8 был в основном натив на xamlc# и xamlcpp.
Кроме гаджетов рабочего стола
А я раньше думал, что все эти лаги, тормоза 100% CPU - это следствие того, что Пуск и все Metro-приложения написаны на C#...
да, да, успокаивайте себя. Когда учился в универе, не то что приложения на C# - сама среда Visual Studio работала даже на нетбуке, а вот для запуска приложений на Java пришлось менять пк
Плюсую. Тоже в универе после C# была джава и андроид студия (или как-там оно называется). Ноут стоически вынес испытание и запуске эмулятора, но я пару раз об него обжигался. Та же ситуация была с Qt-creator. Студия работала заметно шустрее.
Странно сравнивать запуск C# приложения прямо внутри ОС с Android эмулятором который как минимум крутил ещё одну ОС внутри а как максимум ещё и трансляцию x86 - arm делал. Да и jetbrains-овские ide по своим фишкам были на голову выше visual studio, настолько, что это даже позволяло jetbrains продавать надстройку resharper к VS, брать за это неплохие деньги и при этом быть мейнстрии продуктом (в компании где я работал тогда покрайне мере были лицензии закуплены и без него люди жить не хотели). Так что тут не совсем сравнение java и c#, а скорее - совсем не)
По фичам они были, может, и правда на голову выше - но и по тормозам тоже. До сих пор помню как отключил на своём рабочем компьютере унаследованный решарпер - студия после этого таааак быстро заработала!
Но вы тоже правы, решарпер был написан на C#, и тормозить ему это не мешало, так что дело не в языке.
С тезисом про тяжелость эмулятора соглашусь.
Но мы также и на самой джаве писали, но в какой ide я уже не помню - 10 лет прошло. Я так по удобству инструментария и выбрал себе язык.
позволяло jetbrains продавать надстройку resharper к VS
Фишки крутые, но тормозила так, что я перекрестился и удалил это чудо. В дальнейшем, уже будучи C# разрабом, пробовал возвращаться к ней на более мощном железе, но производительность также не впечатлила. Мои коллеги тоже без него обходились.
В отличии от Rider, это просто царская ide.
сравнение java и c#
Не думаю, что дело в языке и технологиях. Скорее, мое железо его не тянуло и оптимизации решарперу явно не хватало :с Ну, и мы все-таки обсуждали инструментарий :)
сама среда Visual Studio работала даже на нетбуке
Visual Studio 6 сносно работала на Pentium 1 @ 75 MHz с 16 мегабайтами памяти.
Но 6 студия, которая ещё только для сей была, даже по сравнению с первой дотнетовской, (2001 вроде?) была крайне устаревшей и нефункциональной
Ну, знаете, размер и номер студии не главное, важно умение с ней обращаться. Я встречал одного парня, у которого вообще была пятая студия, но он делал с ней такоооооое! ^ ^
Смотря когда, я работать начинал на пятой, шестёрка тогда только вышла. И там таки не только C, но C/C++ )
. И там таки не только C, но C/C++ )
ну студия 2002 была уже для C#, J#, C/CPP (.Net),VB.Net
я на сях не писал но в студию заходил чтото в сишном проекте потыкать, по тем временам я там запутался насмерть... я тогда писал на VB6 ...и переход на 02 студию перешел как к себе домой, а 6 была прям чемто из ископаемых времен по ощущениям
Пф... Пользуюсь ей до сих пор, брат жив, полет нормальный.
Мне НЕ НУЖНО автодополнение, если оно открывается не мгновенно, а через полсекунды. Мне не нужен редактор кода, где набирание символов на экране немного запаздывает за клавиатурой.
Ну, у меня символы не запаздывают. Правда, всякие автодополнения, автозакрытия скобок и т.д. и т.п. у меня выключены: я терпеть не могу, когда среда разработки что-то делает за меня.
вам лично не нужно, а мне нужно
это чистая вкусовщина, вы минусы по субъективным признакам ставите?
код писать и в блокноте и в консоли можно, там ничего не запаздывает
вам лично не нужно, а мне нужно
Мне тоже нужно, но мне нужно, чтобы оно открывалось мгновенно. IDE, которая полчаса думает, меня не устраивает, я возьму старую IDE, которая молниеносно реагирует.
Это ваши личные предпочтения
Я же просто указал что на момент выхода 2002 студии, шестерка выглядела откровенным анахронизмом, что вам очень сильно не понравилось и вы агрессивно начали реагировать
Быстрая реакция IDE это отличная фича которую редакторы кода подрастеряли за последние 20 лет превратившись в монстров, это правда
но я и вообще большинство пользователей IDE пользуются ими, потому что "скорость печати" не настолько критичная фича чтобы отказываться от других плюшек которые более ценные
Сам C# достаточно быстрый язык, все зависит от конкретной технологии отображения, я начинал на Windows Forms и там было нормальным делом бухнуть лениво прямо в интерфейс табличку на 20 колонок и 30 тысяч строк и все это моментально отрисовывалось и сортировалось на дохленьких компьютерах с 1-2 ядра и гигом оперативки и быстро подгружалось по внутренней локалке, приложения не для интернета были и пользователей было мало.
Для современных технологий такое в принципе непредставимо, убьет абсолютной любой комп с любым количеством оперативки и ядер даже не смотря на то что отрисовка еще и на GPU делается, а тогда все на процессоре.
Поэтому во всех веб-фреймворках куча сложнейшей логики с виртуальными элементами когда отрисовывается только десяток элементов непосредственно на экране, которые может потянуть технология, а все остальное моментально скрывается - я здесь уже не столько про SPA фреймворки сколько про библиотеки компонентов для них например в Element Plus для Vue есть отдельно Select и отдельно Virtualized Select для больших объемов данных, и то же самое с таблицей ну где-то это не выделяют в отдельные компоненты, а с самого начала встраивают. Насколько я понимаю на Хабре было примерно то же самое, когда перевели комментарии с JQuery на Vue они начали дико тормозить, потом прикрутили виртуализированную отрисовку и одно время было заметно как при прокрутке они с задержкой прорисовываются.
На C# Windows Forms заменили на WPF, которая гораздо круче и удобнее в плане разработки, но многократно медленнее, потом заменили на UWP которая еще медленнее, ну а теперь и сам C# забросили и пишут десктоп на вебе, который еще дай бог если не на порядок медленнее.
И я думаю в вебе даже не в JavaScript проблема, хотя он очень медленный язык, но вряд ли интерфейс упирается в вычислительную сложность, а именно в самой технологии отрисовки страницы, HTML и CSS изначально не были рассчитаны на сложные интерфейсы.
На C# Windows Forms заменили на WPF, которая гораздо круче и удобнее в плане разработки, но многократно медленнее, потом заменили на UWP которая еще медленнее, ну а теперь и сам C# забросили
Поправка: C# не забросили, язык-то как раз развивается (скоро выйдет C# 14). А вот с GUI-фреймворками под .NET - катастрофа. Ну вот Avalonia есть.
Да, само собой, я имел в виду только GUI разработку. Сам язык живет и в других сферах активно развивается. Народ его явно любит например затащил в геймдев по сути чуть ли не вопреки усилиям майкрософт который XNA похоронили вместе с кучей других неплохих технологий.
Avalonia выглядит круто, но последние новости не то чтобы тревожные - они собираются большое количество новых и давно ожидаемых фич перевести в закрытую часть и продавать по подписке (визуальный редактор форматированного текста, hot reload и еще длинный список). Сложно их этим попрекать - компания маленькая и денег у них мало и подписка дешевая. Но как открытый проект теряют привлекательность, да и как коммерческий в подсанкционных странах.
Я все хотел перевести эти статьи от них для хабра но так и не собрался. Надо бы собраться.
Тут у нас уже скоро как 10 лет есть официальный мультиплатформенный .net и C# на серверах под линуксом без проблем highload тянет. Проблема в кривых руках и "у нас 30% кода пишет ИИ", а не в языке.
Говнокод можно написать на любом языке. Но насколько я понимаю сильно огрубляя популярные языки можно распределить по скорости на три группы:
самые медленные PHP, JavaScript, Python
середина C#, Java, Go
самые быстрые C, C++, Rust
Но в любом случае C# никогда в число наиболее медленных языков не входил.
Современные языки, использующие JIT виртуальные машины (c#, java), обычно по скорости не сильно уступают нативному коду, где-то даже могут быть быстрее. Но это утверждение со звездочкой так как на то чтобы добиться этого JIT компилятору нужно какое-то время потратить на оптимизации параллельно с работой программы, либо заранее собрать программу в нативный код на целевой машине.
Ну вот в JavaScript есть JIT но например сборщик для Vue и прочих фреймворков Vite переписали на Go (в смысле раньше был webpack на javascript, на замену ему написали Vite на Go) и заявили о десятикратном ускорении, компилятор TypeScript сейчас переписывают на Go и тоже заявляют о почти десятикратном ускорении. В обеих случаях это люди из сердца экосистемы JavaScript и им вроде как нет смысла как-то принижать свой язык.
Потому что этот сборщик запускается один раз, делает своё дело и выключается. А JavaScript хорош там, где он крутится в фоне в бесконечном цикле: Гуйня всякая и анимации.
Грубо говоря там где скорость самого языка не важна и большую часть времени программа проводит в ожидании либо действий пользователя либо сетевого запроса.
Написать JIT для языка с динамической типизацией несколько посложнее, чем для C#/Java, и возможности оптимизации более ограничены - скажем, нельзя просто передать число в функцию в регистре и сразу с ним работать, в очередном вызове там может прилететь строка и это надо корректно обработать.
Проблема не в языке, а в том что все современные UI фреймворк - тормозное говно. И это не ограничивается C#. А обычным разработчикам деваться некуда - кушают что дают. Не имеет значение как хорошо и продуманно написан твой код, если в реальности 99,9% времени процессора будет отнимать нижестоящий код UI библиотеки.
Есть конечно вариант вернуться к WinForms но что-то не хочется, да и привязано гвоздями к Винде.
Что характерно, авторы Mono в свое время пытались запилить кроссплатформенный и открытый вариант Windows Forms но их купила Microsoft и закрыла этот проект. Формально они вроде с Linux сейчас дружат, по факту до сих пор плетут кое-где интриги вокруг его поддержки.
Но сам Windows Forms конечно очень сильно устарел и по внешнему виду и по архитектуре и по поддержке современных возможностей в интерфейсах. Что не удивительно для нескольких десятилетий без развития.
Как мне кажется, по скорости разработки небольших шаблонных интерфейсов без особого дизайна (который реальным бизнес пользователям никогда не нужен был) и просто входа новичков они до сих пор даже самые современные технологии превосходят.
Скоро у них не останется разработчиков, знающих WinAPI.
А потом WinAPI удалят из Windows, и всех заставят переписывать приложения на веб-технологиях.
Так уже, Webview пихают куда только можно.
вы перепутали Windows с MacOS - это там каждый год выходят обновления, которые гробят даже системные приложения
Обновляюсь уже хрен знает сколько времени, ещё с первых MacOS X, ничего особо не ломалось. ЧЯДНТ? :)
вы ничем особенным не пользуетесь, вот ЧВДНТ
макос отдельно знаменита тем что после апдейта версии ОС может проловина софта просто перестать работать и все..."обратитесь к своему вендору за обновлением своего софта для поддержки очередной версии"
А читать список изменений совсем не судьба?
Всмысле?
по каким изменениям в МакОС надо понять что условный "фотошоп старой версии" перестанет работать в новой ОС? типа "в требованиях старого фотошопа не указано что она поддерживается?" - так после винды это дичь страшная за таким следить. подавляющее число софта обычно без проблем переживает такие апдейты...в макосе это всегда рулетка
вот буквально на днях читал историю как 1С окуклился после обновления версии макоса.....вот просто "не поддерживается и всё"...умельцы уже руками пакет распаковывали и запускали
а "необновлять ОС" в случае с маком это тоже такой себе путь
ок, мне для работы нужен Xcode. Поскольку куча разных проектов, то на компе нужен хотя бы Xcode 15 и 16 одновременно (чтобы отложить миграцию проекта на последнюю версию Xcode). Что мне делать? Варианты ответов:
обновиться до Sequoia - Xcode 16 работает, Xcode 15 отваливается
остаться на Sonoma - Xcode 15 работает, Xcode 16 - нет
обновиться до последней Sonoma - Xcode 15 работает, Xcode 16 почти работает кроме "ии автодополнения кода"
Причем в списке изменений этого конечно же не пишется
чтобы отложить миграцию проекта на последнюю версию Xcode
А можно по подробнее? Я просто уже наверно лет 6 как начинаю пользоваться новым Xcode начиная с beta2 и вроде никаких особых миграций не приходилось делать. Может быть просто делаю на автопилоте и не обращаю на это внимание.
Навскидку:
- сторонняя библиотека Внезапно ломает поддержку старых версий Xcode в cocoapods:
https://github.com/AppLovin/AppLovin-MAX-SDK-iOS/issues/393
- аналогично для SPM:
https://github.com/1024jp/GzipSwift/issues/66
Ни разу такого не случалось у меня. Софт всякий стандартный, IDE, фотошопы и премьер, ещё всякого вагон.
Даже при смене архитектур (x86->arm) большая часть продолжила работать без проблем, не говоря уже об апгрейде ОС.
Так что, я думаю, если такое и случается, то крайне редко.
пока у меня был мак, я проходил версии 10.11->10.12->10.13 и ВСЕГДА я натыкался на какието костыли...всякие парагоновские драйвера, утилиты корпоративного ВПН, уже забылось за давностью но и какойто совсем прикладной софт у меня помирал
самое жесткое было когда я юзал какуюто нишевую софтину которая писалась под Lion и сдохла в 10.12...и все..а ее больше не существует в старой версии, а в новой она типа ребрендинг и облачная версия с 10% функционала старой
И у вас старые 32битные игры из стима работают, да? Ведь так?
Я не юзаю стим и не играю на ноуте :)
Я думаю можно найти без проблем то, что не взлетит. Моя мысль в том, что утверждение что в макоси после каждого апдейта что-то ломается - ложно.
Тем не менее на обратную совместимость они забивают больше чем винда или линуксы.
Насчёт винды соглашусь, а вот насчёт линукса... это вряд-ли.
Как обычные проблемы с зависимостями, так и всякие forward/backward-compatibility с GLIBC.
Единственный надёжный способ - полностью статический бинарник, собранный с MUSL вместо GLIBC. И то до тех пор, пока всякие вызовы ядра вдруг не поменяются (ну это уже маловероятно).
Как правило, так или иначе, но способ запустить старый софт найдется. Придется возможно помучаться, но он хотя бы заработает.
но способ запустить старый софт найдется. Придется возможно помучаться, но он хотя бы заработает.
ага, виртуалку поставить со старым линуксом?
Тот же докер, как вариант, простое решение достаточно, при этом влияния на производительность минимум, поскольку все же не виртуалка.
Это в том случае если к ядру чтото гвоздями не прибито...не смогу сходу привести такой софт но я на такой натыкался, когда уже в бытность массовой 3й версии ядра, мне приходилось ставить бекпортированную 2-ю на более новый дистриб
p.s. это было в до-докер времена но чтото мне подсказывает что докер тут не помог бы в той ситуации
Всего лишь Flatpak.
ради интереса в 2020 пробовал выкачать старый utorrent ~2010 года (потому что он кроссплатформенный):
- win 10 только ругается на безопасность файла. Правим настройки безопасности - файл запускается и работает
- macOS говорит, что приложение не запустится - и все
Я сейчас на яблочном силиконе спокойно запускаю скопированный с предыдущего интел мака софт. Задолго до этого при переходе на интел тоже можно было запускать софт предыдущей архитектуры.
версию macOS, характеристики обоих пк и название софта в студию
Прошка late 2019 и прошка M4. Макось последняя. Вот скрин первого что вспомнил, еще было несколько, в том числе с гуем.
Правильно - android studio написан на java, на который перекладывает заботу о поддержке разных ОС, с чем там все очень даже хорошо. Т.е. проблемы вы увидите только если вовремя не обновите java.
А что насчет не-java приложений?
А где там в platform tools java то? Я сишечку вижу. Можно пруф?
Прежде чем троллить, изучите матчасть.
А к чему здесь ссылка на Rosetta? Я спрашиваю у Гугла, на чем написаны ваши android studio и platform tools:
Android Studio and its platform tools are primarily written in Java and Kotlin, with some parts of the core infrastructure using C and C++.
Что я делаю не так?
А к чему здесь ссылка на Rosetta?
А вы почитайте что там написано.
Что я делаю не так?
Спрашиваете у гуглобота? Он часто врет.
https://android.googlesource.com/platform//packages/modules/adb/
что именно я должен там прочитать? Что Розетта - это поддержка приложений под intel на apple m процах? Так разговор шел не о смене архитектуры, а о том, что при любом очередном major обновлении Макос вы рискуете получить пачку перечеркнутых иконок приложений, которые больше не запустятся.
Вторую ссылку я тоже не понял
Вам напомнить с чего началась эта ветка?
Я сейчас на яблочном силиконе спокойно запускаю скопированный с предыдущего интел мака софт.
Вторую ссылку я тоже не понял
Покажите где там java.
Я сейчас на яблочном силиконе спокойно запускаю скопированный с предыдущего интел мака софт.
нет, ветка началась с того, что apple не может обеспечить совместимость с приложениями даже при просто обновлении macOS. Если я правильно понял скрин, то вы используете Android Studio (в основном Java) и Android Development Tools (в основном Java) + ADB (c++), если неправильно, то в свою угадайку играйте сами.
А еще вы даже не приложение в пример приводите, а выцепили из приложения какой-то отдельный модуль и рассказываете, что он не использует java. Ну и? Может вам повезло, и он не использует библиотеки, которые менялись при обновлении.
А еще в командах android tools я не особо разбираюсь, и вы их не объяснили - может вы просто ерунду вывели на экран.
нет, ветка началась
Нет, конкретно это обсуждение началось с моего коммента про силиконы. Не передергивайте.
Если я правильно понял скрин, то вы используете Android Studio (в основном Java)
Я не использую студию, и на моем скрине это ясно написано.
А еще вы даже не приложение в пример приводите, а выцепили из приложения какой-то отдельный модуль и рассказываете, что он не использует java.
Какой отдельный модуль, какая java? Такое ощущение что с чатботом разговариваю.
А еще в командах android tools я не особо разбираюсь, и вы их не объяснили - может вы просто ерунду вывели на экран.
No comments.
No comments.
Вы на полном серьезе считаете, что при обсуждении тем, касающихся macOS, все присутствующие должны разбираться в консольных командах android developer tools? А еще видимо должны уметь читать ваши мысли?
Какой отдельный модуль, какая java? Такое ощущение что с чатботом разговариваю.
давайте пройдем по вашей ссылке выше:
git clone https://android.googlesource.com/platform/packages/modules/adb
не модуль, но лежит в разделах "packages" и "modules". Я так понимаю, на этом разговор можно закончить?
в консольных командах
Да какие консольные команды еще? Я вам ссылку дал на исходники adb, можете попробовать поискать там java.
не модуль, но лежит в разделах "packages" и "modules".
Platform tools это отдельный софт, отдельно можно выкачать и установить. Технически это один из компонентов Android SDK.
Я вам ссылку дал на исходники adb, можете попробовать поискать там java.
нет, вы дали сначала ссылку на документацию apple по Rosetta (вообще не в тему). А потом ссылку на некий багтрекер, на котором кроме ссылки на исходники adb еще куча ссылок и текста. Что с этим делать, я так и не понял, но выкачивать целиком репозиторий я точно не буду.
Platform tools это отдельный софт, отдельно можно выкачать и установить. Технически это один из компонентов Android SDK.
так вы сами путаетесь - говорите про platform tools, а ссылку даете на один из его компонентов. Отсюда ваше непонимание, что на каком языке написано.
И еще дословная цитата из Гугла выше ответит на ваш вопрос про java. Зачем вы его задаете в каждом сообщении?
вообще не в тему
Отмотайте на несколько комментов выше.
Что с этим делать, я так и не понял
Ну ок. Но зачем тогда лезете в дискуссию в которой вообще ничего не понимаете?
И еще дословная цитата из Гугла
Вам тут суют исходники а вы тут про "цитату из гугла". Ну ок. Я снова повторяю - зачем вы начали и продолжаете дискуссию в которой вообще ничего не понимаете?
о, теперь я понимаю - вы пишете про одно, скриншоты скидываете от другого а ссылки от третьего. А под конец когда вас уличили в этом, вы спрыгиваете с темы. Т.е. вы или набрасываете рандомную информацию на вентилятор, или сами не понимаете, о чем пишете, но хотите, чтобы кто-то вас поддержал в этом. А смысл?
На Линуксах нормально с обратной совместимостью тоже только у приложений на WinAPI
Для старых 32-битных игр у меня остался старый мак, с совместимой ОС.
Первая macOS c 64bit ядром — 10.6
Последняя macOS поддерживающая 32bit программы — 10.14
Они почти 9 лет поддерживали 32bit программы, сколько еще должны были?
Ну вот windows до сих пор поддерживают.
С софтом проблема эта меньше стоит чем с играми, софт либо все таки хоть как то обновляют, либо альтернативы появляются, а вот даже не такие уж старые игры как выпустили 32битными, такими они и остались.
Справедливости ради, с поддержкой старых игр (особенно конца 90х под ранние версии directx) в windows тоже далеко не идеально - иногда без обработки напильником (отдельными любителями или профессионалами из gog) запустить бывает тяжеловато.
Ну вот если на винде проблема запустить игры 90х, начала нулевых, то на маке проблема игры середины десятых запустить. Особенно визуальные новеллы подобным грешат часто. Ну, из того что заметил в своей библиотеке стима.
На винде (у большинства пользователей) не было такой серьёзной смены аппаратной плаформы (при том что на маках архитектура проца менялась не раз и не два). Хотя интересно посмотреть, как виндовые игрушки середины десятых запускаются на железяках на базе Snapdragon X Elite.
Судя по обзорам на ютубе что мне попадались - вроде запускаются в целом. Не идеально конечно и не шустро, но как то работают. Хоть с частью и бывают проблемы вроде вылетов или не запуска.
прикол в том, что macOS часто не может обеспечить совместимость даже в версиях, где смены аппаратной платформы не было
Обработка напильником обычно сводится к подкидыванию dll от старого Direct X в папку с игрой) По крайней мере та же GTA фиксится именно так)
Они почти 9 лет поддерживали 32bit программы, сколько еще должны были?
Понимаете, вопрос "должны" немного некорректный. Они не должны вообще ничего сверх публичной оферты, а с точки зрения их бизнес-логики поддержка должна заканчиваться примерно на следующий день после окончания ими же установленных сроков гарантии. Просто чтобы вы побежали покупать новое несмотря на то, что старое еще могло бы послужить лет десять-пятнадцать, если нагрузка по потребной вычислительной мощности сопоставима с аппаратными возможностями. Вот у Windows, несмотря на многочисленные спорные моменты во всех их инновациях, как-то получается поддерживать 32-битное legacy, причем нет причин, по которым эта поддержка внезапно исчезнет в обозримом будущем. И, опять же, современные версии Windows вполне прилично работают на многих устройствах лет по пятнадцать от роду, позволяя выполнять как новый, требующий этих самых современных версий Windows софт, так и довольно дремучее legacy. Вопрос лишь в том, чтобы хватало вычислительной мощности под конкретные задачи. Нередко хватает, и бежать покупать новое только потому, что для вас искусственно создали условия, в которых еще годное старое уже не работает адекватно, не требуется. Только ради увеличения вычислительной мощности, если ее очевидно недостаточно.
ничего не ломалось? Ну обновитесь с Sonoma до Sequoia - с некоторой вероятностью отвалится... Keychain. Если что - чтобы пофиксить это, нужно удалять какие-то системные файлы, относящиеся к keychain с возможной потерей сохраненных паролей.
Обновлялся, конечно, только недавно, ничего не отвалилось. Но допускаю что мне просто повезло: точнее я просто жду, обычно, до 1 или 2 сервисного релиза перед обновлением.
Привычка ещё со времён винды - "до 1 сервис-пака не юзать" :)
Есть такое. На большей части из сотни маков была такая проблема. Удаление файлов keychain помогает не всегда, так что пришлось делать
"чистую установку".
А можно список этой половины? Ну и пруфы на "отдельно знаменита" хорошо бы.
Обновляю макось примерно с 2013 года на разных устройствах - никогда никаких проблем не было.
Xcode уже минимум дважды ломался с обновлением major версии macOS - приложение самой apple.
А вы не только браузером пользуетесь "с 2013 года на разных устройствах"?
Xcode это уже половина? =) Я сходу могу вспомнить little snitch - в каком-то обновлении макоси были существенные изменения в сетевой подсистеме (не нужно уже было свой kext для фильтра), и технически если остаться на старой версии LS, то фильтр работать не будет. Но фишка в том, что разрабы LS выпустили апдейт софта с поддержкой новой подсистемы еще во времена беты макоси с этими изменениями.
А вы не только браузером пользуетесь "с 2013 года на разных устройствах"?
А вы сами как думаете? Или вопрос ради под#%нуть?
Я спрашивал про браузер, потому что мне уже попадались странные пользователи macOS. У одного macOS и Xcode с проектами влазит на 128gb ssd (и видимо еще свободное место остается) - в то время как у меня с аналогичными задачами 512gb мало. Другой писал про мощность макбуков и стабильность Макос, а как начали разбираться, оказалось, что он только в соцсетях сидит и видосы на ютубе смотрит
влазит на 128gb
Макоси для инсталляции нужно порядка 20-30Г, xcode после установки занимает примерно столько же (не сам апп, а все что оно по системе распихивает). Сложить две цифры справитесь? Что там лично вам нужно я хз.
про мощность макбуков и стабильность Макос
И в чем проблема? Лично я видел вылет в панику на макоси только один раз за 12 лет (и то это было на очень старой макоси), по причине бага в vmware fusion. Про скорость можете сами бенчмарки посмотреть.
вот поэтому и задавал вопрос про браузер
Макоси для инсталляции нужно порядка 20-30Г, xcode после установки занимает примерно столько же. Сложить две цифры справитесь? Что там лично вам нужно я хз.
Имеем 128Гб ssd. 30Гб xcode, 30Гб система (допустим вы в ней редко работаете и она не захламляет так как у меня, поэтому ок, пусть будет 30). А вы не хотите отнять 128*0.3 =38.4Гб свободного места, потому что иначе у вас система будет тормозить? 30Гб осталось? А вы не учли, что проекту нужны сторонние библиотеки, которые захламляют диск временными файлами, а с появлением SPM место съедается еще быстрее, потому что в 99% случаев SPM вам выкачивает на диск не отдельно взятую версию, а весь репозиторий целиком со всей историей.
И в чем проблема? Лично я видел вылет в панику на макоси только один раз за 12 лет (и то это было на очень старой макоси), по причине бага в vmware fusion. Про скорость можете сами бенчмарки посмотреть.
А я за 14 лет насмотрелся всякого. "Стабильность" системы - это не обязательно "экраны смерти". Keychain, убитый очередным насильно навязанным обновлением - это еще ничего. У меня однажды макбук отказался принимать пароль (просто потому что) - помогло только загрузиться в безопасном режиме и еще раз перезагрузить в обычном. И никакие синие экраны винды не сравняться с этой уникальной возможностью на ровном месте вместо работающего пк получить кирпич.
А нарисованные бенчмарки я больше не смотрю. В случае с процессорами M оказалось, что производительность macos сравнивалась не с настольной версией винды, а некой недовиндой, адаптированной под arm процы.
А вы не учли, что проекту нужны сторонние библиотеки
А вы спрашивали у того человека какие проекты он там запускает? Может быть ему полтора гига с головой на все хватает?
А я за 14 лет насмотрелся всякого.
Я вот тоже насмотрелся, но далеко не на макоси. Единственное что еще могу вспомнить - были иногда глюки при наборе с клавиатуры, починили следующим релизом через месяц емнип.
А нарисованные бенчмарки я больше не смотрю.
А на какие вы смотрите? По моим ощущениям (сравниваю с предыдущим макбуком на core i9), софт работает стабильно быстрее. Не просто визуально отрисовывается, а сами функции софта. Самое первое что заметил - бэкап в Joplin делается буквально за две секунды, вместо секунд 20-30 на i9. И много еще где, хоть та же работа с IDE от JetBrains. Про просмотр/кодирование 4K HDR видео я даже говорить не буду. И при всем при этом, на M4 кулеры у меня запускались только пару раз - на бенчмарках и на компилировании чего-то большого из homebrew. И то далеко не сразу в момент запуска тасков.
а зачем вы сравниваете макбук на М с предыдущими моделями на Intel? Вы сравните с ноутом на intel хотя бы того же года выпуска. Если сравнивать макбуки разных годов выпуска производительности, то например, xcode previews работают отвратительно и там, и там.
Очень странное явление - процессор сделанный на техпроцессе на три поколения лучше и современней почему-то быстрей. Извиняюсь за сарказм.
В случае с процессорами M оказалось, что производительность macos сравнивалась не с настольной версией винды, а некой недовиндой, адаптированной под arm процы.
Чипы у них все же реально удачные получились. При том что предпочитаю линукс а макось недолюбливаю (хоть это у меня и основная рабочая машина, по причине того что со сборкой под ios иногда возиться надо + важно время жизни от батареи). Была возможность сравнить m1, m1 max, и i7-10750H. Все они примерно в одно время вышли. Остальные характеристики железа были вполне сравнимы. И вот на ноуте с интелом андроид приложение у меня билдилось в полтора раза дольше чем на m1. И где-то вдвое дольше чем на m1 max. При этом интел очень сильно и быстро грелся, так что система охлаждения ноута даже просто при работе в андроид студии шумела достаточно заметно, а при сборке прям пылесос включался, и от батареи ноут на интеле раза в три меньше жил. От ос это не зависело, скорость сборки примерно одна была что на винде что на линуксе. На маке же система охлаждения у меня слышна только когда запускаю LLM на 14b+ параметров (и это кстати еще один их плюс, можно гонять достаточно современные LLM на камне 2020 года).
10750H - техпроцесс 14нм, M1 - техпроцесс 5нм. Это не процессор лучше, это лучше техпроцесс его производства при чем сразу на три поколения - после 14нм были еще 10нм потом 7нм и потом только 5нм. Сравнивать вообще бессмысленно, сравнивать имеет смысл только процессоры на одинаковом техпроцессе то есть по сути уже с Meteor Lake каким-нибудь Core Ultra 9 185H или еще более точно с 5нм - Ryzen каким-нибудь Ryzen 7 7840H.
Тут конечно можно сказать что Intel сама виновата что пролюбила производство и не стала заказывать у TSMC, но так или иначе эта разница ничего не говорит о качестве самих процессоров, их мироархитектуры, о качестве x86, она говорит о качестве их производства.
Почему бессмысленно сравнивать? Да, более тонкий тех. процесс вполне себе серьезное конкуретнтное преимущество и аргумент для выбора машины. Когда эти Core Ultra 9 185H вышли, и когда M1? Несколько лет разницы. Когда я сравнивал свои ноуты - этого Core Ultra 9 185H еще даже близко не существовало.
Ну как минимум сравнивать надо не процессоры, а именно техпроцессы производства. Потому что такое отставание ничего не говорит о качестве самого процессора и его архитектуры. А многие сравнивая x86 на 14нм и ARM на 5нм делают громкие выводы о том что ARM энергоэффективней например.
Ну или например делают выводы о том что именно процессоры Apple лучше, хотя на самом деле лучше техпроцесс TSMC.
С чисто потребительской точки зрения конечно если на 5нм в данный момент есть только Apple то имеет смысл рассмотреть к покупке Apple а проблемы Intel с производством это проблем Intel.
Но сейчас они все примерно сравнялись и все делают на TSMC.
Мы сравниваем какой проц лучше было выбрать потребителю в 2021 году. Причины почему он шустрее и энергоэффективнее потребителю не важны. Ему важны именно производительность, горячесть/холодность, сколько ноут от батареи живет.
Ну пока люди не начинают рассуждать о том, что вся причина в особой энергоэффективности ARM или какой-то особой убогости именно микроархитектуры от Intel - то да.
Ну есть еще одно отличие, которое для работы LLM важно. То что RAM на SoC и более быстрая. По факту apple сейчас единственные ноуты на которых можно с адекватной скоростью модели на 70B параметров запускать.
Я не пытаюсь сказать, что маки полная дрянь. Есть у них свои преимущества и свои недостатки. Как и у любой техники. Я исключительно про то, что из факта превосходства конкретной реализации их процессоров в конкретный момент времени на конкретном техпроцессе делаются широкие и явное неверные выводы о превосходстве ARM в целом или ее конкретной реализации от Apple. Ну а безумные фанатики у всех бывают и у Apple, и у Intel и у AMD и много у кого еще.
Я например так и не люблю на ноутах работать - как по мне нормальная работа невозможна без пары больших мониторов, а если на стол влезли два 30+ монитора, то влезет практически любой десктоп и ноут теряет смысл как основной рабочий компьютер.
Ну и локальный запуск LLM нужен пока тоже не всем, особенно в текущем их виде, как я понимаю даже 70B моделька заметно уступит топовым, а тот же DeepSeek и на Маке не особо поднимешь.
Конкретно в России стоит учитывать санкционные ограничения.
На всякий случай, все вышенаписанное не означает, что маки говно.
Я например так и не люблю на ноутах работать - как по мне нормальная работа невозможна без пары больших мониторов
Согласен полностью. Правда у меня конфигурация 2 по 28" друг над другом + справа от них 16" ноута как вспомогательный.
а если на стол влезли два 30+ монитора, то влезет практически любой десктоп и ноут теряет смысл как основной рабочий компьютер.
А вот тут не согласен. Раз в несколько месяцев нужно в офис в другой город кататься, пару раз в месяц езжу к родственникам в деревню. Мне без ноута никуда. Причем именно долгоживущего (ну и плюс макось по работе нужна, для того чтобы ios разработку тыкать, сам то я для всего остального рабочего предпочел бы на линуксе сидеть, но увы).
Более того, у меня еще и второй дешевый ноут есть, 10" трансформер. На линуксе. Беру в покатушки на велике, на шашлыки, на диване поваляться. В общем в тех случаях когда есть шансы угробить технику либо когда полноценным 16" двухкилограммовым пользоваться не очень удобно.
ПК у меня тоже есть, но он больше для игр (в частности VR) предназначен + запускать относительно небольшие (8-14b) LLM для автокомплита/автопереводов, все таки на видеокарте полноценной они заметно шустрее, пока в память влезают.
Ну и локальный запуск LLM нужен пока тоже не всем, особенно в текущем их виде, как я понимаю даже 70B моделька заметно уступит топовым, а тот же DeepSeek и на Маке не особо поднимешь.
На M3 ultra его запускают вполне, в память влезает и работает, пусть не очень шустро, хоть все равно быстрее чем на intel/amd. Но это уже не ноут, да.
Что не всем это нужно - соглашусь, но я принципиально не люблю облака и те сервисы, что недоступны локально. Вынужден конечно пользоваться, когда нет альтернатив, но если они есть - предпочту локальное решение.
>Раз в несколько месяцев нужно в офис в другой город кататься, пару раз в месяц езжу к родственникам в деревню.
Для таких редких случаев я закупил вспомогательный ноут в дополнение к основному десктопу.
>Более того, у меня еще и второй дешевый ноут есть, 10" трансформер. На линуксе. Беру в покатушки на велике, на шашлыки
У вас явно нетипичный случай. Просто ради интереса - а что вы вообще делаете с 10-дюймовым именно ноутом на покатушках на велике, на шашлыках? Как по мне все потребности в таких ситуациях удовлетворяет даже не планшет, а телефон.
>На M3 ultra его запускают вполне, в память влезает и работает, пусть не очень шустро
Вот прямо полную версию на 671 миллиард параметров? И именно на ноутбуке, а не на МакСтудио с 512 Гб памяти и который стоит 5 тысяч долларов? А можно поподробнее и со ссылками?
Я видел здесь на Хабре обсуждения где ее пытались запустить на домашнем сервере с 768 ГБ оперативки, а все остально было не про оригинальную их модельку, а про сильно упрощенные варианты.
Ну и сам DeepSeek сейчас уже далеко не передовая модель, насколько я понимаю они по уровню как ChatGPT 4o полугодовой давности. Очень жду их новой модели.
>я принципиально не люблю облака и те сервисы, что недоступны локально
Да я в принципе тоже, но у современных облаков как правило слишком много преимуществ - например система рекомендаций у стриминговой музыки которая для меня массу новых исполнителей открыла.
Для таких редких случаев я закупил вспомогательный ноут в дополнение к основному десктопу.
Настраивать рабочее окружение сразу на двух машинах лениво. Да и, повторюсь, нужно ios иногда тыкать (последние месяцы так вообще только этим почти и занимался, хоть и в android studio).
У вас явно нетипичный случай. Просто ради интереса - а что вы вообще делаете с 10-дюймовым именно ноутом на покатушках на велике, на шашлыках? Как по мне все потребности в таких ситуациях удовлетворяет даже не планшет, а телефон.
Нормальная клавиатура + полноценная ос в целом заметно удобнее чем мобильные почти во всех задачах, и под настроение на природе покодить, конфиги системы поковырять, когда перерыв в той же покатушки после 50км делаешь на отдохнуть.
Вот прямо полную версию на 671 миллиард параметров? И именно на ноутбуке, а не на МакСтудио с 512 Гб памяти и который стоит 5 тысяч долларов? А можно поподробнее и со ссылками?
Если не заметили - я там дописал что речь не про ноуты. И да, оригинальную, но квантованную, q4-5 запускают. Качество там проседает далеко не так сильно как на distill моделях.
https://www.reddit.com/r/LocalLLaMA/comments/1j9jfbt/m3_ultra_runs_deepseek_r1_with_671_billion/
Но да, она уже далеко не топ. qwen3, имхо, чуть получше будет, или как минимум не хуже. При меньшем числе параметров.
Только не надо ещё и архитектуру с микроархитектурой в одну кучу мешать )
Имеем 128Гб ssd…
Простите, а вы про внешние ssd слышали?
Так ведь уже пытались так сделать, не взлетело.
Так и не понял как убедиться что оно написано на React Native.
Сама MS утверждает, что отдельные компоненты Windows 11 написаны на React Native https://devblogs.microsoft.com/react-native/rnw-settings-win11/
Подебажить?
Пользователи выяснили это из твита, в котором нет никакого объяснения?
Нет времени объяснять, ведь это уже "выяснил" какой-то чёрт, кодящий с помощью ИИ на питоне.
Это может проверить любой и убедиться в том, что это приложение каждый раз нагружает на десятки процентов (от 40% до 80% в зависимости от конфигурации ПК) как минимум одно ядро ЦП по клику на кнопку «Пуск».
Проверил, нагрузка вырастает в пределах 4% на довольно древнем i9-9900 (с тех пор уже несколько архитектур сменилось и у процессоров появились энергоэффективные ядра, которые и берут на себя такую работу). Причем, после открытия меню она возвращается к исходному значению. Откуда у него там берётся 40% - пусть сам и выясняет.
Не хочу вас возвращать в безжалостную реальность, но всё же i9, пусть и шестилетней давности - не средний по больнице проц. Вполне себе существуют i7, i5 и, даже, страшно сказать i3. Так что, возможно, вы как раз и описали методы разрабов винды - "у кого не топовый проц этого года, пусть сами выясняют, что за проблемы".
Впрочем, в данном конкретном случае вы, вероятно, правы, поскольку на скрине довольно свежий i7.
Я сверился с безжалостной реальностью перед написанием комментария. Ноутбучный i7-1365U со скриншота в статье - более-менее выступает на равных с 9900 (14% это не так много, учитывая кратную разницу в теплопакете).
у меня i3 проработал в основном компе лет 10-11. Я даже и не знал, что он страшный. Но почему?
Однопоточная производительность не сильно отличается внутри i9, i7, i5, i3 одного поколения и в основном зависит от теплопакета. А в многопоточности ReactNative я сомниваюсь.
Только разницы в количестве ядер в i5-i7-i9 нет, если нагружается только одно из них.
А касательно "откуда эти пики" - черт знает какие там процессы под капотом возникают, может индексируется что-то, с диска считывается, а учитывая живые плитки в 10-ке той же - они обновляются и отрисовываются.
А тот же диспетчер задач отображает мгновенную нагрузку, а не сглаженную, т.е. если пик в 100% длился 0.001мс и именно в этот момент произошла отрисовка графика - диспетчер и покажет эти 100%, хотя сам комп в целом эту нагрузку даже не заметит. Сглаженная нагрузка показывается только в общем графике цпу, притом непонятно по каким алгоритмам она считается.
Во-первых, архитектура не меняется уже порядка 20 лет -- и называется AMD64/Intel 64; меняются же микроархитектуры.
А во-вторых, i9 -- топовые процы, а прирост производительности на одно ядро стагнирует примерно те же самые 20 лет (грубо говоря, мощнейшее ядро 2025-го года не факт что будет хотя бы вдвое производительней на "коде общего назначения" по сравнению с мощнейшим ядром 2005 года; вот на специальных задачах с помощью новых команд -- это да). Так что даже на старом i9 всё должно работать быстро, а вот на новейшем i3 -- очччень не факт.
А при чём тут i3, если у сорокопроцентного чувака мобильный i7? У него там 6 энергоэффективных ядер и 2 производительных. Причем, эти эффективные ядра не особо уступают стареньким ядрам Skylake+++. Ну, сделаем скидку на то, что мобильный проц задушен по TDP. Всё равно не очень понятно, откуда взялись 40%.
а вот на новейшем i3 -- очччень не факт
В однопотоке десктопный i3 двенадцатого поколения, разумеется, обойдёт десктопный i9 девятого поколения.
Что оно там, это React-приложение, сразу все 8 ядер грузит что ли?
слышал, что по производительности в среднем core i3 такие же, как i5 предыдущего поколения, i5 как i7, i7 как i9. Это не так?
скорее нет, хотя очень зависит от поколения
Например, в старых процессорах i3 и i5 одного поколения были вообще одинаковые, разница была в заводском разгоне и каких-нибудь фишках типа speedstep, turboboost, ht и т.д.(и однозначно не должны были стоить х2)
В некоторых поколениях это было разное количество ядер, например 2 vs 4. В это случае более новый 2-ядерный процессор все равно почти во всех сценариях сильно проигрывал старому 4-ядерному
Иногда новое поколение было просто переименованное старое, иногда с минимальным заводским разгоном(+100-200 мгц).
это возможно и было какое-то время, но недолго
да и как сравнивать, эти градации по кол-ву ядер отличаются (молчу про энергоэффективные и мощные ядра, которые где-то есть, где-то нет, где-то мало одних, но много других, где-то наоборот)
Вообще никак не связано и зависит от кучи переменных. Например при смене поколения может обновиться и архитектура и техпроцесс и тогда будет резкий скачок в производительности. А может вообще не поменяться и будут изменения в рамках считанных процентов. А могут решить напихать в например в i7 дополнительных ядер и оно практически сравняется со старым i9.
На 13700k 2-3% но как то странно считается. Это 50-70% на 2 ядра и еще по 10-20% на 4 ядра.
Вы смотрели общую нагрузку на процессор или на 1 ядро? В статье говорится именно про нагрузку на 1 ядро
У меня на i5 2500 с 3% выросло до 30 на десятке. Думаю, в 11 похожий эффект.
4% на ядро или на проц?
А то мне в свое время один товарищ доказывал, что 1С не может тормозить из за проца, так как ест всего 12%. И по отдельным ядрам тоже все хорошо.
Угу, на восьмиядернике. И ее время раскидывается по всем ядрам. А то, что 100/8 = 12,5 это мелочи.
Пользователи в соцсети X выяснили, что кнопка «Пуск» в Windows 11 (обычно статичное меню с ссылками на другие приложения) — это плохо оптимизированное приложение на React Native. Это может проверить любой и убедиться в том, что это приложение каждый раз нагружает на десятки процентов (от 40% до 80% в зависимости от конфигурации ПК) как минимум одно ядро ЦП по клику на кнопку «Пуск».
Это отвечает современным требованиям - проще и дешевле разработка, больше нагрузка - прожорливее система и дороже компоненты, т. е. железо нужно чаще обновлять(покупать новое). Даже Линукс сегодня встал на этот путь.
Это отвечает современным требованиям руководителей и менеджеров - проще и дешевле разработка, больше нагрузка - прожорливее система и дороже компоненты, т. е. железо нужно чаще обновлять(покупать новое).
fixed
А программисты это сплошь перфекционисты, которых хлебом не корми, а дай код повылизывать, или легаси порефакторить.
Иные программисты конечно тоже не ангелы, но клепать релизы один за другим, думаю не их идея.
Думаю если программистам начнут платить деньги за оптимизацию, они начнут оптимизировать.
В случае с открытыми проектами... ну большинство их них вроде ядра Линукс или браузеров давно уже тоже крупными компаниями разрабатываются, но там если начнут платить хотя бы вниманием - ну люди банально перестанут использовать плохо оптимизированные проекты и резко кинуться использовать оптимизированные, то тоже начнут.
Так никто, абсолютно никто не готов больше платить за оптимизацию (в коммерческой разработке деньгами, в некоммерческой временем). Редкое исключение - это высоконагруженный бэкенд где могут переписать с Go на Rust потому что Rust быстрее. Но даже там это не так часто встречается.
Будут люди готовы платить - начнется оптимизация.
Даже Линукс сегодня встал на этот путь.
Единственное что объединяет все разновидности линукса это ядро. А ядро очень хорошо оптимизировано по сравнению с виндой. При этом там функционал вшит который винда уже вообще никогда не реализует.
который винда уже вообще никогда не реализует
А если через WSL?
Проще и вероятнее, что винда перейдёт на линуксовое ядро.
Думаю, что они до сих пор этого не сделали только из-за лицензионных ограничений.
Не из-за этого. У Линуха (как и у многих Унихов) сильно хуже родной API ядра (в частности, нет асинхронного ввода-вывода и потоков; вместо последних -- костыли с отображением нескольких процессов на общую память; в стандарте POSIX предусмотрено и то, и другое, но Линух ни разу этому стандарту не следует). Что ещё важней, у Линуха постоянно ломают внутренние механизмы ядра, из-за чего драйверы от старых версий не годятся для новых -- а переписывать старые, естественно, никто не спешит. Из-за этого, в частности, под всякое древнее встраиваемое железо зачастую используют жутко древние версии линуховых ядер: обновиться невозможно из-за необходимости переписывать чуть ли не все драйверы.
В Винде, за исключением видеодрайверов (чья драйверная модель была полностью переделана при переходе на Висту), совместимость сохраняется, поэтому корректно написанный драйвер для Вин2000 можно перетранслировать и использовать в современной Винде. (Правда, не все они корректно написаны, но это уже второй вопрос: сама система совместимость на очень неплохом уровне сохраняет).
Ну, не знаю насчёт реакта, я потестил у себя - при нажатии на пуск цпу начинает есть dmw.exe, т.е. виндовый процесс отвечающий за отрисовку рабочего стола и окон. Пуск видимо тоже окно.
Ест много, если спамить пуск, но я обычно так не делаю, а на одиночном нажатии ничего странного не наблюдается.
Это может проверить любой и убедиться в том, что это приложение каждый раз нагружает на десятки процентов (от 40% до 80% в зависимости от конфигурации ПК) как минимум одно ядро ЦП по клику на кнопку «Пуск».
Шокирующе. Жаль, что враньё, как "может проверить любой" (с).
>Это может проверить любой и убедиться в том, что это приложение каждый раз нагружает на десятки процентов
Убедился. Не нагружает.
Только фотку уместнее Дэвида Катлера, который наиболее известен как архитектор Win NT, но и до этого разработал несколько систем. В частности, RSX-11, которая была многозадачной многопользовательской, но под себя жрала меньше 100 Кбайт памяти, включая драйверы (т.е. реально меньше, чем абсолютно убогая МС ДОС).
Панель задач, ее элементы и центр уведомлений написаны на C++ с использованием WinUI.
Так это, не просто кнопка а всё меню, и контекстное меню с новым видом тоже и скорее всего новая оболочка файловой системы туда же. А это в свою очередь скорее всего как запуск любого отдельного приложения, вызывает всплеск потребления памяти и юзает ядро.
чет какое-то лпп, у меня core i3 12100, открытие пуска вообще никак не влияет на нагрузку цп, иногда при открытии пуска она падает. ЧЯДНТ???
UPD перепроверил еще раза 4, вообще никакой связи между нагрузкой на цп и открытием пуска не выявил, винда 11 24H2
Это как в руле обнаружить дополнительный маленький двигатель от кордовой модели.
Проверил на своём планшете с Atom N100. Да, действительно улетает в 100% если спамить кнопкой Пуск. Но, при этом он работал в режиме энергосбережения от батареи, у него экран 2880x1920 и очень дохлый iGPU, а частота ядер в этот момент была всего-лишь 1.2 Ггц. Если бы Пуск был написан на React Native, на этом тазике это было бы сразу заметно.
Что-то не скачет ничего.
И в контексте фотки со Столманом, чем использование ReactNative (если его использовали) поверх WinRT отличается от использования PyQt / PySide и PythonGTK в кедах или гномах, кстати? Или как обычно "их злобный V8" и "наш оптимизированный Python"?
Не особо чем, по мне так и Lubuntu с переходом на Lxqt перестало быть легковесным дистрибутивом для старых систем.
тем что их усиленно не заставляют использовать , в линуксе заменить кнопку pusk почти штатная опция
почти штатная опция
"Почти штатная" - это как? А то может оказаться, что на Windows это тоже почти штатная.
которой никто не пользуется из не-гиков, да
вон взять убунту с гномом...многие тюнят этот интерфейс?
людей кто ставят разные нетиповые (за пределами, гномубунту, минт и прочих кед с lxde) DE можно в погрешность статистики записать
а вопрос был "чем отличаются" а не "многие ли". точно так же немногие на винде кнопку пуск меняют, вот здесь же мы видим некоторое количество "гиков". перепахать все при желании на линуксе несколько проще, причем софтом из официального репозитория, инсталяторы линукса при старте несколько оболочек предлагают., а можно вообще все вырезать
В Винде - тоже, а со времён восьмёрки и вполне популярная.
И вот эту фейковую новость теперь растащат, чтобы толкать очередные репчаки и оптимизаторы (и хорошо, если платные, а не просто протрояненные).
Никто ведь не будет разбираться, даже тут в комментариях большинству по сути наплевать, правда это или нет.
Человек буквально насрал в Twitter без пруфов, в лучших традициях идиджборд - новость. Вы в /hw/ на Дваче еще зайдите, напишите статью про input lag на процессорах AMD (которые почему-то есть только если у тебя процессор Intel).
люди в это охотно верят, потому что 11 венда на самом деле тормозит но не дают никакого визуального "вау" взамен. у меня по 7 сек "мой компьютер открывается" если турбобуст не включить, который на ноутбуке гонит проц до 100 градусов. пускай поставят седьмую венду и посмотрят как это должно работать, и ведь они визуально не сделали ничего особого
Я, конечно, всякого ожидал от переводчиков хабра, но «start menu» перевести как «кнопка пуск» — это слишком. Я сначала и правда подумал, что на React Native написана только сама кнопка (встроили как эксперимент в нативный интерфейс, например), но все же речь в оригинале идет про меню, а не про кнопку.
Явно и вся панель задач:
Решение проблемы очевидно и элегантно - добавить руткит, скрывающий загрузку ЦП этим компонентом.
вот почему Пуск так тормозит — кто бы мог подумать, что там React Native
Windows, Escape, Alt-Пробел, Закрыть.
Если вы понимаете, о чём я.
В ноутбуках топят за энергоэффективность, сильно снижая базовую частоту, поэтому даже такие простые вещи, как меню Пуск вызывает заметную в рамках диспетчера, но малозаметную в работе, нагрузку.
Стоит понимать, что это заметная нагрузка в рамках 1.8Ггц, если установить базовую частоту или буст в 2.5-3Ггц или выше на постоянной основе, это и будут те самые 1-2 процента нагрузки, которую получают пользователи с десктопными процессорами, у которых базовая частота всегда выше.
По итогу - ничего нового. Windows становится все тяжелее с каждой версией.
А что, писать "загружает ядро" вместо "нагружает" — это уже нормально?
А кто-нибудь обращал внимание , что чтобы посмотреть загрузку проца, памяти и т.п. - запускаешь "Диспетчер задач" и зачастую, он в первой десятке по потреблению этих ресурсов. (Браузеры не в счет - там аномалии)
Не удивлен - это меню у меня всё время тормозит жутко. Удивлен тому, что оно не предзагружено в оперативу, что ли...
Процитирую заголовки на Хабре:
• моё разочарование в софте;
• медленный софт;
• в софте всё всрато и становится ещё всратее;
• раздувание кода стало астрономическим;
• в софте всё восхитительно, но все недовольны;
• софт становится хуже?
А истина одна: вопреки желаниям бизнеса, продактов, очередных выдумщиков 1001 фреймворка (который точно-точно ускорит разработку!) нужно возвращать инженерную культуру в программирование. Биты экономят байты, байты - килобайты, килобайты - гигабайты. Если выбросить все эти Reactы и прочие прослойки - софт будет летать.
Большинство людей использует компьютер также, как и 20-30 лет назад, делает абсолютно те же вещи. Разница только в болоте блоаткода, библиотек и обвесок, которые растут с каждым годом, засасывая в себя индустрию. "Пуск" на React - лучшая иллюстрация этого процесса.
Я плюсую ваш комментарий, но парадоксально с вами не согласен. Попробую объяснить, что именно вызывает у меня несогласие - считайте это попыткой конструктивного диалога.
Биты экономят байты, байты - килобайты, килобайты - гигабайты. Если выбросить все эти Reactы и прочие прослойки - софт будет летать.
Здесь еще согласен. Уровень согласия - 146%.
Большинство людей использует компьютер также, как и 20-30 лет назад, делает абсолютно те же вещи.
Уровень согласия падает до где-то 99%. Потому что то же самое в принципе теперь выглядит красивее, красивость тянет ресурсы, но от этой красивости никто в среднем отказываться не захочет. Иносказательно: 20~30 лет назад я смотрел видео в разрешении 320х240. Сейчас я тоже смотрю видео, но только HDR, да и размер растра до 4K подрос - реалистичность и как следствие вовлеченность выросли, пусть в принципе ничего и не изменилось, поэтому я не хочу назад, а наоборот мечтаю про еще больше вперед. Или, например, игры. Я не особо любитель игр, но будь я игроманом, то проходить снова и снова игры с качеством изображения как в Doom, как бы я не любил Doom и как бы это не было невероятно круто в свое время, я уже не хочу - возможности создавать все более и более вовлекающие в игровой процесс видеоэффекты требуют все большей и большей вычислительной мощности, тогда как откатываться назад по уровню технического качества изображения в целом и эффектов в частности не хочется вообще никак. Так то в принципе почти все новые игры это все тот же Doom, Warcraft или что-то еще, только на новый лад - на новых, ранее недоступных технических средствах отображения.
вопреки желаниям бизнеса
Здесь уже не согласен. Не получится ничего хорошего сделать вопреки желаниям бизнеса - бизнес это не благотворительность, которая за счет рептилоидов исполняет ваши или мои желания, нет. Бизнес это то, что на нас зарабатывает. Пока мы это покупаем (опция: пока мы соглашаемся быть товаром сами) - будет именно так, как выгодно бизнесу. А бизнесу выгодна быстрая дешевая разработка, даже если в результате получается неэффективный код, потому что мы сами покупаем компьютеры (телефоны, etc.) со все большей и большей вычислительной мощностью. Значит, неэффективности кода все время есть куда расти.
Разница только в болоте блоаткода, библиотек и обвесок, которые растут с каждым годом, засасывая в себя индустрию. "Пуск" на React - лучшая иллюстрация этого процесса.
Нет, лучшая иллюстрация этого процесса - мысли любого из нас вроде "что-то оно тормозит, пойду-ка я куплю новый компьютер помощнее". И так везде, от микроконтроллеров до рабочих станций.
Уровень согласия падает до где-то 99%. Потому что то же самое в принципе теперь выглядит красивее, красивость тянет ресурсы, но от этой красивости никто в среднем отказываться не захочет.
Не только красивость. Концептуально по-прежнему конечно туда-сюда байты гоняются, но на если с прикладной точки зрения смотреть - софт для новых задач тоже появляется. Та же синхронизация файлов с облаком, например. Мессенджеры современные куда больше фич имеют чем старые (от возможности проведения опросов, до подсветки синтаксиса кода прямо в сообщении). Стабильность софта в целом тоже подросла. Особенно учитывая что квалификация разработчиков, имхо, в среднем снизилась. Если бы все эти люди писали на технологиях 20летней давности - боюсь все ломалось бы вообще на каждый чих. В целом за счет той же иммутабельности которую довольно активно используют, и более высокого уровня абстракции - количество багов поменьше. Ну и да. Размеры картинок/видео подросли, разрешение мониторов - это все тоже ресурсов требует.
С другой стороны не могу не отметить, что есть проблема карго культов и оверинжиниринга, в той же мобильной разработке, например. Плюс использования веб стека для сложных интерфейсов, что приводит к огромным затратам ресурсов машины на отрисовку всех этих сложных зависимостей верстки + стилей + еще js крутится для всякого, который как бы не джитился - все равно будет не очень шустрым, в сравнении с C/C++/rust/go.
Я плюсую ваш комментарий, но парадоксально с вами не согласен.
И это прекрасно, потому что есть повод для обсуждения.
Уровень согласия падает до где-то 99%.
Это не отменяет 47%, с которыми вы согласны.
Потому что то же самое в принципе теперь выглядит красивее, красивость тянет ресурсы, но от этой красивости никто в среднем отказываться не захочет.
Давайте возьмём для примера интерфейс ОС Windows. Полупрозрачность, Frutiger Aero, стиль Windows Vista и Windows 7 был красивым? Да. Нагружал ли он сильно компьютеры на тот момент*? Нет. Более того, на XP с его стандартным движком для разукрашивания окон, всё это тоже помещалось. Со времён Windows 8-10 вообще идёт откат к примитивному, квадратному дизайну, подозрительно похожему на классический. Что мешает взять тот же самый движок Windows XP и на его основе сделать GUI? Тем более, он всё равно где-то внутри ОС остался. Compiz на Linux появился примерно тогда же, когда Vista, тоже позволял прикручивать к окнам разные спецэффекты (но не знаю, насколько был ресурсоёмким).
Сейчас я тоже смотрю видео, но только HDR, да и размер растра до 4K подрос
Видеокодеки - крайне специфичная область программирования, но их можно написать экономно расходуя ресурсы. Владельцы нетбуков в конце 00ых-начале 10ых ставили альтернативные кодеки (CoreAVC и т.п.), которые позволяли смотреть видео в высоком качестве на слабом железе.
Бизнес это то, что на нас зарабатывает.
Именно что! Мы делаем то, на чём они зарабатывают деньги. Грубо говоря, мы им деньги приносим, вместе с пользователями. И к мнению программистов стоит прислушиваться, имхо.
*P.S.: емнип, тормоза GUI в Windows Vista были связаны не столько с красивостями, сколько с попытками MS перетащить части системы, ответственные за отрисовку, из ядра в пространство пользователя.
И к мнению программистов стоит прислушиваться, имхо.
Задача бизнеса - заработать, то есть сильно упрощенно продать товары или услуги. Чтобы успешно продавать, требуются маркетологи, потому что их основная задача состоит в том, чтобы выяснить, чего хотят и чего не хотят потенциальные покупатели. Если выяснить это правильно, перевести в задание для разработчиков и выпустить товар или услугу, то весьма вероятно, что товар или услуга получит платежеспособный спрос. Это то, что нужно бизнесу. Роль разработчика при этом остается критически важной, но не определяющей вектор развития продукта, потому что разработчик знает как сделать, но не знает что сделать чтобы выгодно продавать. Если маркетинг не видит массовой востребованности в оптимизации софта - оптимизация не помешает, но и не поможет продажам в значимой мере, а разработка затянется и обойдется дороже, то бизнесу оптимизация не нужна.
Если лично мною, вами и еще кем-то из читателей нашей переписки оптимизация и востребована, то мы просто не сделаем массовых продаж, которые оправдают затраты на эту самую оптимизацию.
Я понимаю, что в реальной жизни бывает по разному. Кто-то и вовсе проклинает маркетологов, но я это решительно не поддерживаю. Маркетологи выясняют, что мы хотим и что мы стерпим - они не издеваются над нами, а просто дают нам то, на что мы согласимся, если это выгодно бизнесу. Неоптимизированная с точки зрения кода, зато эффективная с точки зрения скорости разработка? Оказывается, на словах нам это не нравится, а на деле мы это покупаем, значит бизнесу незачем увеличивать издержки на оптимизацию, выгоднее гнать быстрее и быстрее. Или, скажем, копроэкономические одноразовые товары, пусть например это будут неразборные телефоны с несменными аккумуляторами - выяснилось, что на словах мы недовольны, а на деле покупаем. Естественно, производство неодноразовых телефонов со сменными аккумуляторами дороже и такие аппараты проиграли конкуренцию. Не спешите винить маркетологов - они всего лишь выяснили, что мы готовы стерпеть. Еще они выяснили, я продолжу пример с телефонами, что нам начхать на стабильность и безопасность, зато мы жить не можем без обновлений - так появились глючные, забагованные, со слежкой телефоны, к которым иногда присылают патчи и мы счастливы, хотя нормально телефон должен быть настолько тщательно тестирован до выпуска в серию, что никакие обновления ему никогда не понадобятся.
Иносказательно: 20~30 лет назад я смотрел видео в разрешении 320х240. Сейчас я тоже смотрю видео, но только HDR, да и размер растра до 4K подрос
Вот как раз для этого на смену Pentium III пришёл i9, чтобы вместо 320×240 смотреть 4K.
А вовсе не для того, чтобы со скрипом выполнять в миллион раз переусложнённый код меню Пуск, написанный деградантами.
Вы сами готовы это делать вопреки желанию бизнеса и клиентов и если вам никто за это платить не будет? Ну вот сделали за рабочий день тот функционал, что запросил бизнес, а после работы остаетесь и оптимизируете и возвращаете инженерную культуру в свое собственное неоплачиваемое время?
Или это должен кто-то другой точно так же делать, а вы так просто порассуждать?
Пока за оптимизацию никто не хочет платить никто и не будет ей заниматься. Это и бесплатного софта касается - потому что там платят временем и вниманием. Это абсолютно логично и закономерно.
Бизнес готов нести издержки за рефакторинг и переработку легаси, когда этот овнокод-монстр вырастет? Рано или поздно, но кому-то придётся это разгребать или переписывать с нуля (!). К тому времени там будет ещё больше исторических пластов и фреймворков, всунутых в систему ради бизнеса и клиентов пары кнопок и меню.
Красивый графический интерфейс Windows можно сделать с помощью технологий, которые существовали в системе ещё во времена XP. Зачем использовать что-то ещё новое для "Пуска"? Никакой обоснованной необходимости в этом нет.
Так чистый, красивый и поддерживаемый код прямо противоположен оптимизации по скорости. Быстрый код как правило очень плохо читаемый.
По скорости быстрей всего на ассемблере писать, только с поддержкой и переработкой легаси вы убьетесь. На крайний случай на C с ручным управлениям памяти, хакеры будут вам благодарны.
Красивый графический интерфейс для Windows может и можно сделать, хотя вы как-то не уточняете на чем именно. Я например помню такие слова как Windows Forms и даже Clarion, но что у вас в голове прочитать не могу.
Вот только дальше вам надо будет запустить это приложение на Linux, на Маке, на Android и iOS и в вебе тоже надо будет.
И что вы будете делать? Писать под каждую платформу аналог приложения с нуля на совсем другой технологии? А потом синхронно вносить правки и править баги на куче разных языков и фреймворков. Готовы сделать это сами для открытого или бесплатного проекта или убедить заказчиков заплатить за это?
Ну для пуска да маразм учитывая что там в МС и денег куча и програмисты уже есть которые остальные винды писали.
И например недавний новый консольный редактор текста они смогли на Rust написать.
Но пуск это явно нетипичный случай.
Вам надо будет запустить это приложение на Linux, Маке, Android, iOS и в вебе. И что вы будете делать? Писать под каждую платформу аналог приложения с нуля на совсем другой технологии?
В этом случае обоснованная необходимость есть, но даже так я считаю более правильным использовать не фреймворк, а отдельные библиотеки, максимально независимые друг от друга, взять из них необходимый минимум.
>К тому времени там будет ещё больше исторических пластов и фреймворков,
Любой фреймворк гораздо лучше его самописного аналога, по которому вообще нет никакой информации в интернете и собственно говоря вообще нет никакой информации - только (говно)код и все, потому что документацию никто не пишет, а автора давно нету.
Если вы с таким не сталкивались, я искренне рад за вас.
И такие решения, кстати, бывают быстрыми, только радости это никому не приносит.
Отсутствие документации - это другое. Любой проект необходимо документировать, описывать, систематизировать. Если нет никакой информации - то дело в не использовании фреймворков, а в том что разработчики проекта - чудаки. У фреймворков проблема документации решается сама собой с ростом популярности, но это не делает их обязательными.
Где-то в идеальном мире люди работают исключительно с проектами, которые делали умные и хорошие программисты, которые никуда не торопились при разработке, не гнались за авралами и дедлайнами, имели понимающее начальство и клиентов, которые выделяли средства на рефакторинг и написание документации, хороших коллег, которые тоже понимали важность всего этого. И команды на этих проектах не менялись многократно прямо в середине разработки, и никто лихорадочно не дописывал новые куски в другом стиле.
Хм. Была проблема - Fusion 360 отказывалась запускаться на Win 7. Народ озадачился. Вот чего такого может быть в рисовалке, там же всё через 100500 слоёв абстракции? И... оказалось, что если поставить MS IE 11, то всё прекрасно работает под Win 7!
Справедливости ради, MuseScore 4 (программа для написания нот) не захотел работать под Win 7 c таким же IE. Это конечно удручает - там хватило бы и функционала Win 3.1
Немного нагружает, да, но не на "30-70%", я вот вижу процента четыре от силы:
Как говорится — ну да, ну ужас, но не "УЖАС-УЖАС!"...
с 2013 по 2018 работал сисадмином на заводе, 70% компов были на XP, 20% на висте и 10% на 7-8. В основном 1С, Outlook с офисом. По возможности XP переводил на висту с добавлением ОЗУ, меня больше интересовало Group Policy, а с XP работать со скриптами я не хотел. К банкротству завода на XP оставалось 15% машин, где-то 50/50 были виста и 7. Висту до сих пор очень люблю, шикарная ОС.
По возможности XP переводил на висту с добавлением ОЗУ
но почему на висту? переходить надо было 7, она как ни странно была легче для компов чем виста
есть такое мнение, но по моему опыту при равном количестве ОЗУ но при более старых ЦПУ, особенно на одноядерных P4/Celeron, виста крутится куда бодрее. То есть фактически Виста лояльна к железу для XP.
7-ка тяжелее висты в любом случае. У меня дома есть ноут, он изначально шёл с вистой, я для теста накатил 7 - ноут буквально колом стоит, вернул висту. ОЗУ 4 гб. Для меня эта тема давно закрыта, никому не навязываю, меня никто не понимал в середине нулевых, так что я привык уже.
лично мне приятнее и комфортнее на том же C2D пользоваться вистой.
и есть другой прикол, на очень медленных HDD (например WD GREEN) лучше ставить Windows 8.1 чем 7. Так как 8-ка лучше работает с кешем диска и имеет более продвинутый префетчер, это компенсирует лаги Green'ов, которые регулярны на 7-ке.
Открываю я в проводнике папку с парой тысяч небольших картинок и каждый раз проводник медленно и мучительно на HDD (диск не системный, для данных) строит им всем миниатюры. Почему XnView строит миниатюры один раз при первом открытии, а при повторном достраивает только для новых картинок если они есть, и все летает?
И каждый раз когда я думаю, что я плохой программист, я открываю сайт Яндекс погоды и наблюдаю, как стремительно раскручивается и завывает вентилятор моего 8-ядерного, десктопного, 5-нанометрового Ryzen 7700X который моментально раскочегаривается на 5,5 Ггц с предельной загрузкой на ядро - и все ради того, чтобы отрисовать статичную страницу с одной картинкой и парой десяток строчек текста.
И ведь Яндекс вроде как передовая ИТ-компания России.
Закрываю страницу и успокаиваюсь.
Насколько я знаю, миниатюры в Винде всегда кэшировались в thumbs.db.
Вроде бы даже в Windows 11 это не поменялось.
Выглядит так, что у вас что-то поломалось (файл не создается/пересоздается что-то еще).
>И ведь Яндекс вроде как передовая ИТ-компания России.
Видимо, через собеседования с алгоритмами пролез один не-олимпиадник, который все и сломал :)
Насколько я знаю, миниатюры в Винде всегда кэшировались в thumbs.db.
Нет, это отключаемое поведение.
Если честно, то дело конечно в Яндексе скорее всего в маркетологах и менеджерах, которые на страничку почты потребовали напихать всевозможного никому не нужного говна (а я его не замечаю из-за встроенного в мозг блокировщика рекламы). Но программисты яндекса со всеми их олимпиадами, зарплатами и алгоритмами могли бы оптимизировать даже это.
Пользователи выяснили, что кнопка пуск в Windows 11 — приложение на React Native, которое загружает ядро ЦП по клику