Comments 218
Однако, какая лютая ненависть.
Поддержу негодование.
Мало им секретных лабораторий по всему миру, в которых разрабатывается и испытывается на людях закрытый коммерческий софт. Я также где-то слышал, что в застенках Microsoft до сих пор томятся сторонники free/open source.
Дело в том, что в Microsoft отдельные группы разработки «владеют» отдельными компонентами системы, и обычно они открыто враждебны к внешним патчам. Даже если вы как разработчик компонента принимаете внешний патч, это злит вашего менеджера (из-за необходимости поддерживать этот патч и оправдывать незапланированное изменение дизайна), злит отдел тестирования (они должны убедиться, что изменение ничего не сломает, а вы только накинули им работы), а также злит менеджера проекта (из-за изменения графика разработки вследствие принятия патча). В итоге нет никаких стимулов принимать изменения, внесённые извне.
Так стоп. Это же обычная характеристика открытого софта. Никто не любит левые патчи с левой функциональностью, которая не совпадает с видением автора.
Нет, есть отличия. В открытом софте не любят патчи, не совпадающие с мнением автора. В "других" не любят патчи вообще.
Также не забываем, что в открытом софте если уже есть патч, то он гарантированно где-то внедрён: возможно эта версия с патчем не настолько популярна, однако всё может поменяться.
В "других" не любят патчи вообще.
А есть какое-нибудь сравнительное исследование? Опрос там или что-то ещё? Или может при приёме на работу в MS заставляют подписывать клятву кровью не принимать чужого кода?
Нулевая гипотеза состоит в том, что люди везде примерно одинаковые. Халяву любят, лишний гемор не любят.
Скорее не опрос, а констатация по факту.
Надеюсь, что клятвы кровью никто не подписывает, но только мемы и "народная любовь" вещь очень упрямая. И уточню, что речь скорее не про халяву, а наоборот: привлечение большой головной боли и вместо реализации предложений/патчей/технологий/идей от других делается попытка сделать собственную реализацию (иногда в формате велосипеда).
Смотреть термин "Фатальный недостаток". Например, простой поиск выдал страничку:
Клятву не нужно давать. Просто инициатива наказуема, и вуаля, ты уже сам не будешь никаких левых патчей принимать
Вы когда-нибудь пробовали сделать PR в крупный opens-source проект? Попробуйте, увидите как встретят вашу "инициативу".
Но остается возможность форкнуть и форк самостоятельно развивать.
Ну вот у вас есть приложение А, которое зависит от библиотеки Β(не вашей), которая зависит от библиотеки C через некий пакетный менеджер. Вот вы делаете форк для C - сколько поднадобиться технических усилий(и бюрократических если мы говорим о реальном бизнесе) чтобы все это собирать, разворачивать и поддерживать?
В open source не приходят писать код за халявой и отсутвием лишего гемора ^_^
Точняк, помню как с боями протаскивал довольно банальные фиксы производительности в wxWidgets. Прикол в том, что это, казалось бы, чуть ли не основной козырь
однажды он случайно запустил HDD вместо модема
Сильные раньше были программисты ;)
Пффф... вот если бы он так в сеть вышел, был бы разговор!
Перевод местамт надмозгов. )
Текст (или только перевод) немного странный, но смысл, как мне кажется, очевиден. Ну промахнулся человек и записал строку не в условный /dev/tty1, а в столь же условный /dev/hda. А результат сильно отличается.
Ну, тут, скорее имелось в виду "открыл", или "обратился к..." - издержки перевода... хотя перепутать /dev/sda и /dev/ttyXXX - не самая тривиальная задача =) но ведь осилил!
собрание не проверенных баек, высосанная из пальца чушь и пропаганда
Hidden text
Это не улучшение, а фреймдропы, в результате чего отображается неправильная частота кадров в секунду. Кто-нибудь, расскажите разработчикам Dirt 3, что их игра оказывается работает в 900 кадров в секунду, а то они не знали. Собственно и остальные байки из этой заметки такие-же нелепые.
файловая система NTFS очень надёжна и хорошо протестирована
Настолько надёжна, что, если копировать на диск файлы в несколько потоков (из-под линукс), то диск потихоньку умрёт (сначала снизится производительность, а если этого вовремя не заметить и не "вылечить" диск в родной ему Windows, то с нарастающей скоростью он замедлится до неприличия, а в какой-то момент и вовсе откажется работать). Конечно, кто-то будет говорить, что дескать это линукс виновата - не умеет, не имеет полноценной поддержки, скажите спасибо, что писать в разделы ntfs можно, а не только читать их, но... Может, проблема всё-таки в качестве ntfs и её реализации? Может, проблемы этой файловой системы при использовании в линукс показывают её недоработки, а не линукса?
Нет. Тут целиком и полностью вина драйвера NTFS (Причём их две реализации есть - в userspace и kernel). Драйвер писался путём дизасемблера оригинального, т.к. спецификаций MS на него не давали. Естественно, в драйвере реализовано далеко не всё, а то, что есть, работает кое-как.
В Linux по умолчанию используется NTFS-3G.
NTFS-3G developers use the FUSE file system to facilitate development and to help with portability.
https://wiki.archlinux.org/title/NTFS-3G
https://github.com/tuxera/ntfs-3g/wiki
ntfs3 kernel driver provides
https://wiki.archlinux.org/title/NTFS
https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html
Commercial version of the NTFS driver for Linux.
https://www.paragon-software.com/home/ntfs-linux-professional/
modinfo ntfs3
modinfo ntfs(старая реализация, только для чтения)
Хорошо быть бигтехом с крупнейшей операционкой. Опенсурсные крутые штуки можешь затягивать бесплатно, а свои драйвера никому не давать. Конкуренция же)
Настолько надёжна, что, если копировать на диск файлы в несколько потоков (из-под линукс), то диск потихоньку умрёт
Если это действительно так, то это означает только то, что линупсовый NTFS драйвер - дерьмо.
Может, проблема всё-таки в качестве ntfs и её реализации? Может, проблемы этой файловой системы при использовании в линукс показывают её недоработки, а не линукса?
А почему тогда при копировании файлов в несколько потоков, но под Windows, ничего не умирает? NTFS на диске же в обоих случаях одинаковая.
проблемы этой файловой системы при использовании в линукс показывают её недоработки, а не линукса?
Нет, показывают, что разработчики драйвера ниасилили создать работоспособный драйвер под линукс, даже при наличии утечки исходников. CLI bash осилили а драйвер NTFS -- нет.
Настолько надёжна, что, если копировать на диск файлы в несколько потоков (из-под линукс), то диск потихоньку умрёт
Если это так, то вообще это очень важная информация, явно требующая отдельных исследований (и статей на Хабре:) ). К сожалению, разработчики различных ОС до сих пор не породили единый универсальный стандарт современной файловой системы. И приходится выбирать между существующими системами... в частности в какой ФС должны быть (внешние) диски для хранения данных? Думаю что большинство выбирает именно NTFS, просто потому что у большинства винда, NTFS кажется достаточно надежной по сравнению с FAT, и Линукс тоже умеет с ней работать. А вот насколько хорошо умеет?
в частности в какой ФС должны быть (внешние) диски для хранения данных
Есть еще UDF в режиме Plain build, который для random access media, о которой редко вспоминают и еще реже используют. Который понимают что винда, что Linux. И которая как раз разрабатывалась как 'универсальный стандарт файловой системы'
А вот почему редко используют - мне давно сильно интересно.
Phind пишет что там есть хардлинки и симлинки, но нет альтернативных файловых потоков, расширенных атрибутов или чего-то подобного. Для меня это уже критично.
3.3.4 Extended Attributes
3.3.5 Named Streams
3.3.6 Extended Attributes as named streams
И тут у Microsoft указано, что вроде бы умеет.
Но, вообще, оно для хранения файлов придумано (на тех самых внешних дисках), а не в качестве рабочей ФС. Поэтому, я думаю, все это все можно класть рядом, в файликах - меньше сюрпризов будет для читающих других людей.
Настолько хорошо, что диски живут дольше, так как нет пресловутой дефрагментации ntfs)
Собственно статистика какого нибудь облачного хостинга в этом поможет.
А что значит "злит" ?
Взялся работать - работай.
Какая разница кто является источником изменений.
Превосходство Linux можно демонстрировать по-разному. Например, недавно 16-летний хакер NSG650 представил специальный Windows-драйвер BugCheck2Linux, который запускает Linux на компьютере сразу после того, как Windows зависла с синим экраном смерти (BSOD), причём перезагрузка не требуется.
Забавная штука, но в чём именно здесь состоит демонстрация превосходства?
Превосходство в том, что линукс работает в тех условиях и окружении, где винда сливает.
Наверное, ответкой был бы модуль ядра линукса, который запускает винду (без перезагрузки) после кернел-паник в пингвине.
линукс работает в тех условиях и окружении, где винда сливает
Винда могла вылететь, к примеру, из-за того, что в ней было запущено какое-то сложное приложение с тяжёлой задачей, например рендеринг какой-нибудь 3д-штуковины. А линукс запустится "пустой". И где же тут "те же условия"?
BSOD - обычно либо кривые драйвера, либо кривое железо. Ну, в linux ведь kernel panic не случается же?
Если бы причина BSOD была только в драйверах или железе, то он бы всегда случался на старте системы. На деле же это происходит, когда запускаешь какую-то программу, например, игру. Или когда нажимаешь какую-то кнопочку, например применяешь хитрый фильтр в фотошопе. В обоих приведённых случаях виной всему дрова видюхи. Но система почему-то прекрасно работает, если не запускать эту игру. Так вот, для равности условий линукс должен стартануть с той же игрой или с аналогом фотошопа и применить такой же фильтр, чего конечно же не происходит. Вот поэтому это никакая не демонстрация превосходства, а всего лишь приколюха.
А почему именно на старте системы? Например, возможен такой вариант, что железо начинает усиленно выдавать данные, драйвер не успевает и железка начинает генерить дичь (интеррапты, запись в левую память и т.д.). И это может проявиться только на большой загрузке, явно не на старте. И если железо с драйвером эту ситуацию предусмотрели и обрабатывают, то будет всё ОК. А вот если не предусмотрели, то ... bsod?
Вы сами себе противоречите. Сначала говорите, что BSOD в драйвере случается только на старте системы, а через пару предложений - что падает, если нажать хитрую кнопочку в хитром приложении и виноваты в этом драйвера. Не срастаются как-то эти высказывания.
Если система падает на старте, то это что-то сломалось очень сильно, это какая-то хитрая и необычная комбинация чего-то установленного. Обычно же проблемы вылезают именно в процессе работы. В случае железа - например, разогретая видеокарта начала выдавать сбои в памяти. В случае драйвера - либо ошибка, вызываемая каким-нибудь редким рейсом, или, скажем, фрагментацией памяти, или какой-нибудь off-by-one, например, который раз в год попадает "точно в цель".
Почему вдруг только на старте? Все ветки всего кода драйвера не отрабатывают на старте, все фишки железа во всех комбинациях не используются на старте. Есть где-то в коде драйвера глючный кусок кода, когда управление дойдёт до него - тогда и упадёт. Я не писал драйверов, но писал как-то альтернативную систему логина ещё под Win2000/XP, которая интегрируется в систему и, если чо, тащит её за собой в синий экран - тоже, казалось бы, ну, логинишься ж на старте. А вот фиг там, где только оно у меня не падало.
Мне на самом деле плевать, где, как и почему оно там ломается. Я лишь хотел отметить тот факт, что в данном случае винда падает при выполнении задачи, после чего стартует линукс без каких-либо задач. Ни о какой демонстрации превосходства тут не может быть и речи.
Да мне, на самом деле, плевать, плевать вам или не плевать, мне интересно, с чего вы взяли, что если система упала не на старте, а упала позже в процессе эксплуатации, то причиной падения не могут быть кривые драйвера или железо?
Если железо кривое, то в чём тут превосходство линукса? А если драйвера кривые, то где тут демонстрация того, что под линуксом они не кривые?
В описанной там ситуации нет никакой демонстрации превосходства и быть не может, чтобы продемонстрировать превосходство на одной конкретной ситуации, надо идентично воспроизвести эту ситуацию для обоих ОС, что невозможно для двух столь разных ОС с разным набором софта. Разве что если под превосходством понимать то, что с Линуксом такое вообще можно сделать, а с Виндоусом нельзя, потому что у вас исходников нет, но это больше похоже на бессмысленный фокус-покус. Реально превосходство надо демонстрировать на статистике выполнения схожих задач на схожем софте и близком железе: вот задачи, вот софты, вот железо, на Винде заняло столько-то времени, на Линуксе столько-то, Винда в процессе упала столько-то раз, Линукс столько-то. Да и то, если вдруг софта под нужные задачи на ОС нет, или ОС не работает на нужном железе, это превосходство превращается в теоретический пшик.
Но вы не егозите и ответьте на поставленный конкретный вопрос: почему BSOD по причине кривого железа или плохих драйверов должен непременно случаться на старте системы?
Но вы не егозите и ответьте на поставленный конкретный вопрос: почему BSOD по причине кривого железа или плохих драйверов должен непременно случаться на старте системы?
Не непременно, а "если". Это должно случаться только в том случае, если логика автора и юзера randomsimplenumber верна. Напомню, они считают, что успешный старт системы демонстрирует какое-то там превосходство и отсутствие проблем с драйверами. По факту вы соглашаетесь со мной, что это ничего не демонстрирует, но не прав у вас почему-то я. Ну раз так, ок, я не прав, юзер randomsimplenumber не прав, автор не прав, а вы правы (хоть я уже даже и не знаю, в чём).
Если тяжёлая задача и нет ресурсов, то по-правильному должна падать задача. Винда как-бы не должна выдавать bsod и должна продолжать работать. Если рассматривать гиперболизированный пример: не сумел записать файл в блокноте - и вот винда упала. Ну не должно так быть.
Ну вот пускай запущенный линукс продемонстрирует это.
Линукс тоже не должен намертво зависать когда ты браузером слишком много открыл, однако вот регулярно такое вижу. Работаешь так спокойно с аудио в аудасити, с открытым браузером где запущен ютуб - ХОП и все зависло с горящей лампочкой IO. И ничего кроме ресета не спасает.
Боги помню в доту играл на Линукс. У меня пока игра грузилась вся система намертво зависала. Играл с ноутбука на I3 3-ого поколения с HDD. Студентом учился работать с линуксом ибо говорили "вот винда фу а когда Линукс настроить тогда конфетка будет", в итоге десктоп только винда а в остальном Линукс использую.
Ну и треш. BSoD - это исключение в ядре, и идеология винды в этом случае не гадать, что нужно сделать, а остановиться и защитить данные тем самым. Если у прилаги закончилось адресное пространство - упадет прилага, если нестраничный пул иссяк - винда грохнется, так как что дальше делать непонятно. Если произошло kernel security исключение - тебя возможно имеют, надо остановиться. Если апишка вызвана не на том irql - надо остановиться, пока говнодрайвер не похерил чего. Во всех случаях по умолчанию будет дамп, который может помочь в устранении проблемы. Такова стратегия, и она в целом норм
если нестраничный пул иссяк - винда грохнется
Реально? В виде нет аналога OOM-killer?
Нестраничный пул - это структуры ядра, используемые им самим и драйверами. Кого прибивать в данном случае?
Тогда я не очень понимаю, что имеется в виду под нестраничным пулом. Если физическая память, то её всегда можно освободить, грохнув юзерспейсного приложение и забрать освободившуюся память для нужд ядра.
Сорян, я не помню такого термина, но я и с Виндой давно не работал.
Вас видимо запутала терминология. Нестраничный пул есть в любой операционной системе с виртуальной памятью. Это страницы, залоченные в оперативной памяти для обработчиков прерываний, памяти внешних устройств, отображаемой в адресное пространство CPU, и DMA процессов. К юзерспейсу они имеют косвенное отношение. В том смысле, что активно пользуясь DMA, нестраничным пулом можно сожрать всю оперативку, если уж очень постараться.
Другое дело, что всегда есть процессы, которые можно отстрелить, чтобы освободить оперативку. И с этим приходится бороться. Например, чтобы OOM killer не отстрелил тот же postmaster в PostgreSQL.
Это страницы, залоченные в оперативной памяти для обработчиков прерываний
Обработчик прерываний (их top half в терминах Linux) должны это учитывать, обычно память выделяется заранее.
Маппинг памяти внешних устройств тоже не в контексте прерываний делается, распределение памяти для DMA тоже, вроде.
Вот ни разу с такими проблемами не сталкивался.
Маппинг памяти внешних устройств тоже не в контексте прерываний делается, распределение памяти для DMA тоже, вроде.
И запись в RAM внешними устройствами напрямую (например, средствами NUMA), и DMA требуют предварительно залоченных страниц в RAM. Потому что эти процессы процессы выполняются независимо от CPU.
Вот ни разу с такими проблемами не сталкивался.
С OOM Killer? Я же привел пример. Причем неоднократно описанный и рассмотренный со всех сторон.
А если про DMA, то попробуйте сами запустить DMA память-память на весь объем доступной физической RAM, не забыв предварительно включить huge pages, так как иначе каналов DMA не хватит. Сразу же OOM Killer что-то отстрелит.
Сразу же OOM Killer что-то отстрелит.
Ну так я про это и говорил - если ядру будет не хватать физической памяти, оно сначала начнет стрелять процессы, прежде, чем упадет - именно такого я бы ожидал и от виндового ядра. Потому и спросил, неужто нет аналога OOM-killer.
В оригинале Nonpaged Pool. Это специальные буферы ядра, которые ни при каких условиях не попадают в файл подкачки и всегда остаются в оперативной памяти. Используются структурами самого ядра и драйверами для хранения данных, которые должны быть всегда доступны. Ядро выделяет эти буферы динамически, но если какой-то кривой драйвер начнёт пожирать память в этом пуле, то рано или поздно это закончится бсодом. (Как пример, можно тут глянуть https://winitpro.ru/index.php/2017/12/06/high-non-paged-pool-windows/)
Драйвер-то, кстати, подписанный?:)
Он просто написал перехват сигнала с запуском определенного софта (в данном случае ядра линукс). Кто ему мешал запустить ЕЩЕ одно ядро виндовс, чтобы винда вылетала в другую винду без перезагрузки?
Вот и вопрос: кто мешает ядру винды запускать другое ядро (вдруг это очень просто)?
Может проблемы с захватом ресурсов, которые захватило первое ядро; или проблемы с привилегиями; а возможно (Сарказм!) волочащийся сзади парашют?
И если бы ядро линукса запускалось как обычная программа, то никаких приседаний с виртуальными машинами бы не потребовалось бы!
Сарказм: вот ведь пацаны в VirtualBox сказочные неумные?! Нужно было просто ядро линукса запустить!
Не, проблем с ресурсами там явно нет - винда то уже "Встала", отпустив почти все ресурсы (Которые успешно занял Linux).
Опять-же, запускаемый линукс, судя по всему, "добивает" винду, окончательно выгружая её из памяти и высвобождая все её ресурсы... Фактически это мало чем от перезагрузки отличается, а значит и запустить можно что угодно... Даже новое ядро Windows...
никто не мешает, но зачем?
Обычный пользователь что с этим еще одним ядром будет делать? Отлаживать виндовс? Вот и нет такой штатной фичи. В Линукс тоже нет такой штатной фичи, кстати
Больше нет? Вообще в Линукс второе ядро должно как минимум для записи дампа упавшего ядра использоваться. Интересно, как решили этот вопрос иначе.
хм. Тут я не копал так глубоко, но чисто интересно, зачем для записи дампа целое ядро?
Чтобы не повердить данные на диске кривым драйвером ФС, а ядро Windows проверяют сам драйвер перед записью дампа:
Indeed, when the system crashes, the crash dump driver (%SystemRoot%\System32\Drivers\Crashdmp.sys) verifies the integrity of the two dump-context structures obtained at boot by performing a memory comparison. If there’s not a match, it does not write a crash dump because doing so would likely fail or corrupt the disk. Upon a successful verification match, Crashdmp.sys, with support from the copied disk miniport driver and any required filter drivers, writes the dump information directly to the sectors on disk occupied by the paging file, bypassing the file system driver and storage driver stack (which might be corrupted or even have caused the crash).
И если бы ядро линукса запускалось как обычная программа
Оно так умеет. Под линуксом. Смотри User Mode Linux. Только тормозно это.
Когда железо криво работает в Windows и нормально в Linux, фанаты говорят, что это винда кривая, когда железо наоборот, нормально работает в Windows, а криво в Linux, фанаты говорят, покупайте нормальное железо. Я сам в основном Linux использую, но такой "сектантский" подход выглядит, честно говоря, смешно.
p. s. Как раз не так давно был забавный момент на стриме, на одном из каналов про Linux, где, чтобы показать настройку Alt, автор канала поставил Boxes из пакетного менеджера, который у него не заработал, не смотря на то что он ковырял его минут 10-15 :) Заработала flatpak-версия, но там (по его словам) нет прокидования USB.
Когда железо криво работает в Windows и нормально в Linux, фанаты говорят, что это винда кривая, когда железо наоборот, нормально работает в Windows, а криво в Linux, фанаты говорят, покупайте нормальное железо.
То же самое говорят фанаты любой ОС. Windows тут не исключение.
Ээээ конечно да, но вообще-то нет:
> Когда железо криво работает в Windows и нормально в Linux, фанаты говорят, что это винда кривая
Фанаты винды тоже в данном случае скажут винда кривая.
Фанаты могут говорить любую чушь. Но 99% BSOD'ов - ошибки в драйверах.
Те, кто что-то настолько безаппеляционно утверждает, любо болтуны, либо могут сослаться на какие-то статистические исследования. Мне действительно интересно было бы почитать такие исследования, поделитесь, пожалуйста, ссылкой?
99% конечно я загнул для эффекту, но вот, например, такая оценка:
https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/stop-error-or-blue-screen-error-troubleshooting.
There's no simple explanation for the cause of stop errors. Many different factors can be involved. Our analysis of the root causes of crashes indicates that:
70% are caused by third-party driver code.
10% are caused by hardware issues.
5% are caused by Microsoft code.
15% have unknown causes, because the memory is too corrupted to analyze.
Вряд ли вообще можно точнее установить причины из-за работы ядра и драйверов на одном уровне защиты с полным доступом к памяти друг друга. Вот если бы ядро было полностью изолировано на более высоком уровне защиты, то да, статистика была бы объективнее.
Почему тогда последняя убунту свежеустановленная на том же самом железе даже на глаз работает медленнее, чем 15-летняя винда, прошедшая путь обновления xp->7->8.1->10 ?
Потому что снап пакеты. Тугие попытки сделать имьютбл систему от каконикал страшно бьют по ее производительности
В целом на хорошем (читай топовом) убунту работает хорошо и все это незаметно.
Почему у админов локалхостов все ассоциации с Linux связаны с Ubuntu?
Какой из официальных дистрибутивов использовали?
Ubuntu Desktop Edition(Gnome), Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity, Xubuntu
Canonical recognized as a 2021 Microsoft Partner of the Year Winner
https://canonical.com/blog/canonical-recognized-as-a-2021-microsoft-partner-of-the-year-finalist
"...Canonical and Microsoft launched Ubuntu Pro..."
https://ubuntu.com/pricing/pro
Вангую, что использование snap-пакетов было совместным решением c Microsoft.
В Microsoft и Lennart Poettering(Avahi Zeroconf - systemd - PulseAudio)
Lennart Poettering leaves Red Hat for Microsoft and will continue to work on systemd https://www.reddit.com/r/linuxmemes/comments/vu4ywr/lennart_poettering_leaves_red_hat_for_microsoft/?rdt=54385
Намекаешь, что это знаменитое: Embrace, Extend, Extinguish ?
Принять, расширить и погасить? Нет. Основной доход от Azure.
09.12.2014 Snappy Ubuntu Core - первый партнёр Microsoft с Azure.
Tuesday, December 9th, 2014 Announcing Ubuntu Core, with snappy transactional updates!
https://web.archive.org/web/20161031101846/http://www.markshuttleworth.com/archives/1434
09.12.2014 21:28 Представлены Ubuntu Core и Snappy, предоставляющие новый метод поставки приложений
https://www.opennet.ru/opennews/art.shtml?num=41223
Потому что убунту тоже продукт крупной корпорации.
Вообще каноникал вместе с разрабами гнома знатно дискредитируют всю линукс-экосистему.
А где вы видели access под линукс? Или есть аналоги?
Столлман такой: ну да ну да, пошел я нахер.
Одна из "фишек" линукса, почему он может быть быстрее винды: линукс в драйверах (модулях ядра) не сильно держится за совместимость по структурам (и даже иногда api): есть вариант работать быстрее - и вот он уже в ядре линукса, винда отстаёт.
Например, столкнулся с хэш-таблицами в виртуальных файловых системах (раньше были списки): и линуск их навтыкал везде - потому что быстрее. А винда - упс ...
Фишек по производительности много.
Например ядро Линукс гораздо меньше ресурсов тратится на работу с процессами. Меньше метрик собирается про каждый процесс, переключение между процессами проще.
Запустить и остановить несколько процессов в Линуксе работает априори быстрее, потому что выполняется меньше инструкций.
С другой стороны, чтобы качественно что-то померять под Линуксом, нужно гораздо больше усилий, чем под виндой.
Эти вещи просто следуют из архитектуры, и их нельзя изменить.
Разработка под винду отличается от разработки под Линукс именно из-за разницы в архитектурах. Поэтому кроссплатформенный софт все равно будет заточен под одну архитектуру лучше, чем под другую.
В статье к сожалению надергано много преувеличений.
Та же первая картинка с перформансом гита (софт, который написан самим Линусом под Линукс, и портирован на винду с сохранением всей *nix архитектуры), ежу понятно что это сравнение не очень.
Да, это понятно, что в винде накопившегося исторического хлама полно и понятно почему так вышло.
С другой стороны в Линукс очень много чего не хватает штатного. И тоже понятно почему так вышло.
Но оценивать системы только по отдельно взятым бенчмаркам, без учета всего окружения и готовых решений для бизнеса - очень и очень плохо.
Вот у меня Арч быстрее винды работает, ставил только чтоб в Майнкрафт играть. Получил +100% ФПС, выводы виндузятники?
потому что клиент майнкрафта написан под линукс?
Или что именно у вас работает "быстрее винды"?
Давайте померяем где winrar последний быстрее жмет - под виндой или под вайном?
Дядь, это была тонкая шуточка. Там, на арче, не было ничего кроме ядра, пары драйверов и штуки типа DWM. В такой сборке в холостую потребление ОЗУ было в районе 200МБ, а потоков которые хоть как-то грузили процессор на пальцах пересчитать можно. Как минимум из-за этого и был ощутимый прирост в производительности, ибо там не было ничего кроме того что нужно.
Отсюда и шуточка про сравнения линукса и винды в целом. Линух это ОС конструктор из которой собирают что угодно и сравнивать её напрямую с виндой, у которой из коробки идёт млрд сервисов некорректно как минимум.
можно долго ругать винду но в плане стандартизации и совместимости со старым у винды не так всё фатально.
А вот когда дело доходит до убунту и железа которое с ней должно работать то в моей практике дважды встречалось такое что нужна именно такая-то версия убунты и такие то либы. Иначе не заведётся. Оба раза нейроускорители по типу корала. А один раз вообще попросили купить конкретный проц и материнку и их сетевую карту и дали сразу настроенный образ операционки.
<q>Многочисленные исследования показывают, что при выборе продукта пользователи положительно оценивают количество его функций: </q>
В пруфе совсем другие графики, и ... серьезно? пруф 2006 го года???
Дайте-те ка подумать... в залоговке пруфа "At User Interface 11" даже не читали внимательно подумали про 11ю винду ?
В целом в статье много нестыковок. Выше уже указали, что пропаганда какая-то. Еще и по теме которую можно было вполне обосновать.
Если в мире опенсорса это открытый процесс, который несёт пользу и улучшает систему
Ну да, в опенсорсе каждый несёт пользу и улучшает систему, а баги им по ночам проприетарщики подбрасывают.
Сейчас *nix является самой популярной ОС в мире, работая на миллиардах устройств
У меня на планшете установлен андроид4, на этом технически полностью исправном устройстве можно сделать например ничего, даже в интернет зайти невозможно. Миллиарды работоспособных но абсолютно бесполезных устройств.
А что за планшет? У меня Galaxy Tab 3 8.0 лежит старенький с последней стоковой прошивкой Android 4.4.2, читать книжки можно, скачанное видео смотреть можно, Интернет... ну тоже можно, но очень грустно по причине невероятных тормозов.
Ну там же протух браузер, и корневые сертификаты от LE. Половина интернета не откроется
новые сертификаты можно вручную подбросить. проблема не в ОС, где есть механизм обновления сертификатов, а в вендорах, которые забили на обновления.
Дык ещё и *nix не является никакой системой. Как минимум - семейством систем, да и то довольно расплывчатым. Андроид очень далеко от десктопного Линукса, по сути он не используется как *nix
Мне кажется и в Windows и в Linux полно легаси... только оно разное. Взять хотя-бы все эти bash скрипты, это же ужас какой-то а не язык. Аналогично make-файлы (впрочем на мой взгляд все системы сборки странные). Да и сам язык Си уже порядком устарел, инклуды и макросы это далеко не самое лучшее решение.
А в винде много корпоративного шлака. Но NTFS мне нравится, в ней есть ADS которые я приспособил для хранения тегов к файлам. В связи с предстоящим неизбежным переходом на линукс пока непонятно, есть ли там аналог (говорят что есть какие-то "расширенные атрибуты", но не факт что это то же самое). Вообще очень жаль что не пошли по пути интеграции ФС и БД, как предполагалось... это было бы очень вкусно.
ни в одной линуксовой фс нет реализации альтернативных потоков данных файла.
да в *никсовых нет емнип нигде.
с одной стороны это удобно, хотя крайне редко где нужно.
с другой стороны многие проги про них вообще не знают, поддержки в большинстве протоколов нет.
и ими пользуются некоторые вирусы :)
Пишут что в линуксовых ФС есть extended file attributes (XFA, xattrs), в яблочной HFS+ есть "forks". Отличие XFA от ADS в том что там размер вроде как фиксированный и равен размеру блока ФС. Это конечно немного напрягает концептуально, но в целом для тегов подходит (строчка с тегами редко занимает больше 10..20 байт). Но если там хранить много разной метаинформации, то конечно лучше чтобы ограничений не было.
Еще обратил внимание на то, что в статье упоминаются "контрольные суммы". Это довольно интересно, потому что давно уже есть потребность иметь хеши для файлов на уровне ФС без их явного пересчета (особенно актуально для больших файлов, гигабайты и более). ZFS и Btrfs вроде как поддерживают sha256 для блоков данных, и используют их для контроля целостности данных; при изменении блока рассчитывается (и очевидно где-то сохраняется) и его хеш. Имея хеши блоков, вполне можно было бы поддерживать и хеши файлов на уровне ФС, как простой XOR хешей всех блоков файла (причем очевидно, что при изменении блока достаточно сделать XOR хеша файла со старым хешем блока, посчитать новый хеш блока и сделать XOR хеша файла с новым хешем блока, т.е. пересчитывать хеши всех блоков файла не надо). Иметь готовые хеши на уровене ФС очень удобно, к примеру для различных децентрализованных пиринговых сетей. А вот винда (ReFS) как всегда пошла другим путем и хеши там всего лишь 64-битные (а в NTFS их нет вообще), что для идентификации файла во всяких DHT совершенно недостаточно.
Только одни вопрос - а зачем для яблок смотреть устаревшую ФС? ОНи уже несколько лет как перешли на APFS
Зачем XOR? Берем хэш хэшей блоков и получаем обычный блокчейн
XOR это обратимая симметричная операция и очень удобна для того, чтобы быстро обновлять хеш файла при изменении хеша одного блока этого файла. Конечно, большие файлы как правило read-only, но допустим, у вас есть файл на несколько гигов, вы дописали в конец несколько байт. При классическом подходе нужно пересчитать хеш для всех этих нескольких гигов. При моем - только для измененного блока.
А зачем блокчейн?
XOR — необратимая операция.
Разве ?
A xor B = C
C xor B = A
C xor A = B
Логически обратимой называется функция, входные значения которой можно однозначно восстановить по выходным значениям, то есть это биекции. XOR биекцией не является. Вы же говорите о ситуации, когда нам по какой-то причине известно одно из входных значений.
Обратимая функция, это когда зная Y можно найти единственный X такой, что f(X) = y. В нашем случае, f(A, B) = f(B, A) = C. Да, A и B можно найти, но подходящих решений - 2
При классическом подходе нужно пересчитать хеш для всех этих нескольких гигов.
Берем хэш хэшей блоков
Не надо же. Только измененного последнего блока и хеш хешей.
rust
И что там, например, с AVX-512 intrinsics? Я гляжу, с 2018 года issue на github маринуют. А в GCC они с 2016 года есть.
Один старый дед мне сказал, что единственное достоинство С заключается в возможности проверки корректности написанного кода через сторонние сложнючие программы. С++ таким не радует ибо они всё ещё не разобрались с тем что из себя представляют объекты. У Rust эти фичи зашиты в компилятор, но в usafe это всё тот же С++ со своими бесконечным приколами. Новые языки появляются но до промышленных масштабов развился разве что zig
На этом всё
Статью можно в палату мер и весов — показывать, что такое "черри-пикинг"
Чем плох windows:
1. Очень плохая сетевая подсистема (тогда как Linux уже на коммутаторы ставят) на windows нету даже pbr...
2. Постоянные обновления и большой расход трафика
3. Навязывание производителями ноутбуков
4. Система очень тяжеловесная (ну, для windows 11 необходимо минимум 4GB RAM и 64GB на диске), к тому же они будут постоянно расти
5. Неотключаемая телемитрия
6. Платная лицензия
Не могу оценивать, хорошая она или плохая, но она развивается и многое меняется.
Обновления не такие уж и постоянные. В ubuntu пакеты обновляются чаще. Открыл win 11 - в среднем один пакет обновлений раз в 2 недели. По расходу траффика - тоже как бы нет, обновления не такие уж и большие.
Это бизнес и не более. И производителям это самим выгодно. Что не мешает им делать и продавать ноуты без ОС
Ну, как бы, возьмите десктопную убунту с KDE, ей надо тоже порядка 4 ГБ. ДА и маку. Про 64 не тру - у меня винда древнейшая, не чистая, прямо сейчас каталог Windows занимает 36 ГБ и никуда оно особе не растёт. Я бы скорее отметил слабую систему обновлений, так как основное место занимают все эти пакеты от драйверов, темпы и прочая шляпа
Наверное плохо, что она неотключаемая, но в остальном проблема весьма спорная. Спорно то, что телеметрия вообще проблема.
Лол, ну она всегда была платная и что? Только для не корп юзеров она разовая. Я купил себе ключик году в 2011, когда ещё была 7 и прообновлялся все эти годы. Т.е. тоже такое себе.
Хочу добавить, что по диску между Linux и Windows тоже особой разницы нет. У меня Arch с KDE и базовым набором программ - браузер, почтовик, офис, аудио, видео и т.п. И занимает он примерно столько же, сколько Windows с таким же набором программ - чуть меньше половины 120 гигового SSD. Это не каталог Windows, а полное потребление диска, включая Program Files, Program Data, профиль пользователя, файлы подкачки и гибернации. Считать чисто по каталогу Windows некорректно - остальное то никуда не денется и ему тоже нужно место.
У вас какой-то неправильный Арч. У меня под корень выделено 28 гигов, занято 25, установлен гном со всеми свистоперделками, браузеры, почтовики и прочее прочее в DE гнома, а ещё awesomewm, i3 и sway. Последние 3 можно не считать, они достаточно легковесные. Домашняя директория занимает у меня всё остальное, но там как бы нет исполняемых програм.
UPD: забыл упомянуть, что у меня Дебиан, но думаю с Арчем большой разницы в этом плане нет
UPDUPD: посыпаю голову пеплом, не в тот терминал смотрел. Вышеуказанные 26 гигов awesomewm, i3 и sway с разным софтом, причём WM там самые лёгкие.
В любом случае, повторюсь: я считаю все, что занимает место на диске. Включая домашнюю директорию и swap-файл (который достаточно большой, т.к. в него происходит гибернация). Смысл считать только корень? Если корень, условно, занимает 32 ГБ, и вы возьмете диск на 32 ГБ и установите на него ОС, то не сможете работать, т.к. всему остальному тоже нужно место. Я предполагаю, что системные требования тоже берутся из такого расчета.
Домашняя директория в чистом виде толком ничего не занимает. Цфиры не существенно и растут цифры не из-за ОС.
Swap файл это штука с переменным объёмом и он не связан с ОС и может быть и 0.
Действительно, смысл при сравнении ОС, сравнивать именно ОС?
Если корень занимает 32 и вы возьмёте диск на 32, вы сможете установить и работать это будет. Но вы действительно не получите полноценного именно пользовательского опыта. Но это буде вообще ни разу не проблема ОС или её роста.
Нет, системные требования никогда не берутся из такого рассчёта, так как это просто нелепо.
ОС это ОС. Это базовая штука, со своими требованиями к железу. Если мы сравниваем ОС, то надо сравнивать ОС. Я вообще не понимаю, каким образом вам пришло в голову при сравнении ОС сравнивать допом пакеты ПО. И я не понимаю ваших странных аргументом про 32 ГБ диск. Они настолько очевидно неуместные, что даже странно о них говорить.
Более того, изначально мы говорили о том, что существует некоторое требование, так ещё и рост в процессе. Я ставил вин 7 в 2011 году и прошёл с неё до 2024 и вин 11 все обновления. Я её не вычищал специальным образом и не готовил как-то к жизни. Тем не менее, я привожу пример опровергающий слова автора коммента. Нет, винда не требует 64 ГБ и да, она растёт в процессе. Есть логи, обновления, временные файлы, но даже этот рост в рамках погрешности.
Смотрите, у меня на винде, максбуке и лине везде под системой ССД и везде на 512. Но вот именно что везде разный объём данных и разные программы, кроме ряда пересечений. И везде на этом диске занято примерно 200-250 гб.
Но считать по каталогу Windows как раз очень корректно, ведь автор выше заявил, что именно вниде надо именно 64 ГБ и она растёт. Но ни стим, ни хром, ни телеграм не являются частью винды. Они сделаны не авторами винды. У них свои авторы и всё прочее тоже своё. Т.е. енсли в винде что-то из этого, внезапно, начнёт занимать больше места, то крайне спорный вопрос, стоит-ли считать виновницей винду.
Плюс мы не можем воссоздать полностью аналогичный надор программ. Например на маке у меня нет GeForce Expirience, который не умеет нормально удалять паки старых драйверов после обновления. На линуксе у меня нет League of Legends, каталог которой расползся до 25 гигов за годы, из которых файлы игры это порядка 18. Следовательно в вашей парадигме вы предлагаете приписать винде то, в чём она не виновата.
Как я уже отметил, можно ещё как-то попинать винду за достаточно последственный механизм установки и отслеживания ПО на компе, но остальное это некорректно, в рамках разговора именно про винду.
Подержите моё пиво © :-)
Было давно куплено два одинаковых нетбука, 4/32. На одном снесли винду и поставили дебиан, на втором винда осталась. В оба воткнули по флешке на 128Гб. На виндовом дополнительный софт ставился на флешку с ntfs, на линуксячем - на основной диск, на флешке оставлен VFAT, заваленный мультимедией, книжками и доками.
Спустя пару лет винду пришлось откатывать из бекапа — система с ~10 занятых ГБ при покупке дообновлялась до полностью занятого диска и не особо реагировала на очистку места (тут, впрочем, пользователь тоже мог бы и пораньше обратиться).
Дебиан пережил обновления с 10 на 11 и потом на 12 версии, при этом до сих пор система занимает меньше половины занятого места, около 12ГБ. Но да, на дебиане до сих пор lxde, а не KDE. Домашний каталог - ещё 14ГБ. Своп - в zram, места на диске не занимает.
Современные винды в голом виде в 12ГБ занятого системой места не влезут, на дебиане же — помимо офисно-интернетного софта и пары гиг игр ещё и средства разработки и отладки установлены. Такое ощущение, что либо арч ставит всякую хрень по зависимостям, либо набор софта всё ж не совсем базовый.
Современные винды в голом виде в 12ГБ занятого системой места не влезут
Не соглашусь тут с вами: современную винду можно установить так, что она будет занимать порядка 10 ГБ. И это будет установка в поддерживаемом варианте, без вырезания разных компонентов при помощи хаков и т.п.
Вместе с играми, средствами разработки для пары платформ и офисом? И она будет жить в таком объёме несколько лет, обновляясь с версии на версию?
Что пустую можно так установить - верю, так как ту, изначальную винду10 когда-то чистили от предустановленного г и она таки умещалась какое-то время в 10ГБ (по-моему, пару месяцев).
Это бизнес и не более. И производителям это самим выгодно.
Чем выгодно? Наоборот, производители не имеют возможности собрать свое ядро ни для одноплатника, ни для суперкомпьютера. Windows их загоняет в Прокрустово ложе.
возьмите десктопную убунту с KDE
Почему не сравниваете с Raspberry Pi OS? Или наоборот, с HPE Cray OS? Они ведь тоже Linux.
Linux ставят на коммутаторы-некоторое существенное упрощение, происходящего в коммутаторах. Один из примеров mellanox(ныне Nvidia), разработавшая switchdev, и у них OS Onyx де-факто Шелл для настройки чипа коммутатора через switchdev, подозреваю, что SONiC и cumulus делают тоже самое. Но сам сетевой стак остальной да, выглядит местами более производительным. Жаль, что пока в Linux все еще присутствует боль с поддержкой софтинами вроде ceph rdma
Смешное название у статьи, только что-то как-то время не то для веселья, что ли?
Время выполнения общих команд Git
а чо бы ещё старее версии не взять?
Google и другие конкуренты постоянно переманивают самых умных и
талантливых сотрудников. Происходит отток талантливых кадров. Microsoft
вынуждена нанимать на их место студентов прямо из колледжа. В итоге
ребята уровня SDE и SDE II поддерживают огромные системы с кучей кода.
Они хотят сделать как лучше и достаточно умны, но не понимают, почему в
своё время раньше были приняты те или иные решения. Не разбираются в
тонкостях работы своих систем и самое главное, не хотят менять то, что
уже работает. Эти юные разработчики также склонны улучшать систему,
внедряя совершенно новые функции вместо того, чтобы улучшать старые.
Если посмотреть на последние релизы, то Microsoft не исправляет старые
функции, а добавляет новые (далее — цитата):
Позабавило, что в качестве альтернативы предлагается Гугл, где те же самые порядки - цитата из статьи на хабре же "Почему новый дизайн Gmail такой медленный?"
С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».
В стенах компании активно поощряют запуски (launch) — публичные релизы
чего-либо. И то, что продукты могут содержать лишь половину необходимых
фич, не работать, работать только из-под Chrome и прочее — это никого не
волнует, ведь их создателям за это ничего не грозит. Это — норма.Смысл подобный действий заключается только в одном — в продвижении по
службе, поскольку без крупных запусков дальше определенного уровня
пройти не удастся. Вот мы и получаем в итоге сотни ненужных
приложений-чатов, бесконечные редизайны и перезапуски — иначе отдельные
личности не смогут получить повышение.
Впрочем, почему только гугл и майкрософт? А как насчет Эппла?
Похожую историю рассказал разработчик Стив,
работавший в Apple над MacOS X Snow Leopard. Стив по большей части
занимался тем, что исправлял баги во всех основных фреймворках ОС — и по
итогам выпуска ему было отказано в повышении из-за того, что его
присутствие «не было критически важным ни на одном из проектов».Ирония здесь заключается в том, что данная версия ОС по идее руководства
компании должна была стать релизом, в котором все было направлено на
улучшение стабильности и производительности системы. Однако, в то время
как одни ожидаемо работали над стабильностью, другие активно
«пропихивали» в релиз новые фичи вроде сборщика мусора для Objective-C,
чем задержали работу остальных и сделали XCode неюзабельным на несколько
месяцев.
Так что проблема общая для всех корпораций.
Почему в первом скрине сравнивают с Ubuntu, а во втором уже с другими дистрибутивами?
Отвлекаясь от Windows и Linux: статья прекрасно демонстрирует использование приема "вброс", которым тут нередко добывают себе дополнительные просмотры авторы корпоративных блогов.
Суть приема - опубликовать какое-нибудь (лучше - как можно более радикальное) мнение на тему, которая интересна многим и по которой распространены несовместимые точки зрения. И темы древних священных войн - типа Linux vs Windows, как в этой статье - они очень даже подходят для вброса.
Опубликованный вброс как правило привлекает внимание большого количества сторонников обеих точек зрения, сначала - горячих, потом - и всех остальных: одни кидаются опровергать радикальную позицию из вброса, другие - защищать. Короче, возникает то, что лучше назвать иностранным словом flame (есть и русские аналоги, но не хочу подводить Хабр под РКН) - большой поток комментариев, который уже начинает привлекать просто любопытных сам по себе. И, таким образом - обеспечивает статье много-много просмотров, лайков и прочих ништяков авторам корпоративных блогов. При том, что самой компании от того, какая сторона права, а какая - нет, обычно и не жарко, и не холодно. Такая вот получается манипуляция массовым вниманием.
Кстати, для вброса лучше всего использовать что-нибудь переводное, с самой компанией и говорящими от ее лица авторами не связанное. Так компании проще избежать неприязни (обычно нежелательной) одной из сторон начашейся, так скажем, дискуссии. А результат дискуссии, напоминаю, компании, в общем-то вряд ли интересен. И именно такой выбор материала вброса мы видим здесь.
Как к этому относиться - личное дело. Но я рекомендую все же сначала распознать факт испоьзования манипулятивного приема, а уж потом принимать решение, что делать (лично делать вам, естественно).
Я вот свое решение принял: в этой дискуссии не участвовать. Но про использованный прием таки решил написать: конечно этим я отбиваю работу у капитана Очевидного, но вдруг кто не знает?
Отцу-основателю, Дэйву Катлеру (Dave Cutler), уже 81. Интересно, вот нашел на вики (перевод):
Катлер известен своим презрением к Unix. Сказал один из членов команды, работавший с Катлером:Unix — давний враг Катлера. Это как его Мориарти. Он считает, что Unix — это мусорная операционная программа, разработанная комитетом докторов наук. За всем этим никогда не стоял один разум, и это видно.
все так и есть.
Винда - это мумифицированный мамонт на деревяннык костылях, перемотанных китайским скотчем.
Люди, которые умели делать хоть что-то, кроме как "лебезить перед начальством", уже давно уволены. Остались только одноклеточные коньюктурщики, которые неспособны ни на что, кроме как "пастись в очереди у кулера с печеньками". Поэтому винда обросла фреймворками, которые ставятся "один поверх другого", притом что разница только в том, что у последнего "+1 совместимость в каком-то там софте(который может никто и не юзает)", но ведь обновление есть обновление. И все новые программы уже будут опираться на этот новый фреймворк-патч (потому что его версия самая свежая) думая, что заботливые мелкомякотники "делают там что-то умное и полезное", пока те лениво начесывая промеж булок штампуют эти фреймворки один за другим, давно забыв что такое "обновление". А вдруг что-то сломается? Лучше мы его под новой версией выпустим. А ведь оно итак ломается. Поэтому с каждой новой обновой - тысячи синих экранов смерти, то драйвер принтера слетит, то еще что-то. Я не про себя, а про корпоративные новости.
Очевидно, что те, кто стоял у истоков кода - уже давно не с редмондом, а на стартапах и в долине кремния. Все остальные - лишь перематывают падающего мамонта новым скотчем.
Так и живем.
Это просто неконтролируемый рост сложности. Кто были первыми, те заложили основу на пустом месте, и им никто не мешал, они делали что хотели. Те, кто был после них, они уже вынуждены учитывать прежние наработки, их решения уже ограничены той архитектурой, что была заложена до них. Поэтому с каждым новым циклом разработки добавляются костыли, чтобы реализовать что-то, не предусмотренное архитектурой. И раз в n-лет принимается сложное решение допилить архитектуру, что порождает ситуацию n+1 стандарт. И все, кто приходит на поддержку этого многослойного пирога костылей и багов, они не в состоянии разобраться из чего он состоит (да и вряд ли человеку вообще по силам в этом разобраться), и просто наворачивают сверху еще один слой реализации уже существующих технологий, потому что только этот слой им и знаком, они его сами сделали. Получается гора кода, которую никто по сути не в состоянии контролировать, и ее просто "обслуживают": фиксят очевидные баги, добавляют где-то сбоку новый фичи, стараясь не залазить слишком глубоко в основной код, чтобы ничего случайно не поломать, как оно там работает уже давно никто толком не знает, любой случайно задетый костыль может оказаться несущим. Хорошо быть первым и творить, и плохо быть тем, кто приходит на поддержку легаси, когда уже ничего изменить нельзя и никакого пространства для творчества просто не осталось, остается лишь продлевать жизнь полумертвому коду, латая бесконечные баги
Мерзкая ситуация на самом деле. Ресурсов и воли все это выкинуть и реализовать как нужно ни у кого просто нет. Да собственно нет возможности даже просто перечислить фичи, которые нужны, и описать как они должны работать - этого уже никто не знает, экспертиза давно утеряна, люди ушли, а у тех кто еще доступен давно все стерлось в памяти
А в крупных корпорациях все это сдобрено еще и тоннами бюрократии: отдельный разработчик не имеет права ничего менять, пока это изменение не согласуют сто инстанций сверху, что произойдет в лучшем случае через несколько лет, после сотен обсуждений на всех уровнях управления, когда сам автор уже давно давно забыл об этом, или даже уже уволился
Да собственно нет возможности даже просто перечислить фичи, которые нужны, и описать как они должны работать - этого уже никто не знает, экспертиза давно утеряна, люди ушли, а у тех кто еще доступен давно все стерлось в памяти
Наглядно видно на новой версии панели задач в вин11. Они её написали, в итоге оказалось, что не работает половина базовых фич, которыми все пользовались. И плюс потеряна еще куча и более редко используемых.
В 2012 году, когда здесь по общему мнению был уже не торт, было иначе.
Просто в нормальных статьях инструкции были в первую очередь для линуксов.
Ну не позорьте республику, разве нельзя на какую-нибудь другую тему задание "писулька в корп блог" выполнить? Ну обидно же.
На самом деле есть у всего софта такая повсеместная беда - поначалу он шустрый и надежный, потом довольно быстро превращается в огромного, малоподвижного инвалида, страдающего ожирением и массой других серьезных болячек, которые команда медиков пытается лечить, но каждое лекарство даже если и лечит одну проблему, при этом добавляет еще и новые.
Первые версии Винды - довольно шустро работают на железе, которое в наше время и компьютером-то не назовешь. Современная Винда, еле дышит на железе, которое в те времена считалось бы суперкомпьютеров за свою производительность.
Увы, деградация ПО налицо. Бурное развитие железа слишком избаловало нашего брата-программиста. Теперь всегда практически проще и дешевле завалить проблему железом, чем пытаться написать что-то быстрое и эффективное.
Как страшно жить! Понимаешь, не выбрасывают функции! Всё легаси! Раздутый функционал!
А вот не так однозначно. Обратная совместимость у Windows за счёт этого сильно лучше. Не, если поставить голый Центось и с него отдавать статику в инет - спору нет, Центось будет в сотни раз стабильнее. Но вот на реальной домашней системе с кучей разностороннего железа и софта... Обновил Винду с 10 до 11-ой - что отломалось? Ничего. ВСЁ работает.
Обновил Убунту с 20.хх до 22.хх. ОпенВПН перестал работать? Почему? Похерили обратную совместимость - зайди в репозиторий, поправь пару строчек, пересобери либу. Внешняя аудиокарта в Сонаре перестала нормально выводить звук, появился лаг. Почему? Потому. Зайди, скачай, поправь пару строчек, пересобери дрова. Миди клава? Домашний кинотеатр 7.1 через HDMI и + 2 доп. вывода звука? Циско? Шаринг видео в Тимс? Ну вы поняли. Зайди, найди проблему, скачай исходники, поправь, пересобери. А ещё есть и минорные обновления ОС почаще...
Спасибо, я потерплю кучу "ненужного" легаси. Понимаю, немного холиварно, но я несколько раз в своей жизни на домашнем компе пытался избавиться от Винды, довольно долго жил в мультибуте, но, блин, я так не могу. Пока мне для решения моих повседневных задач нужного кодить день вместо того чтобы два раза кликнуть на ярлык - я не готов тратить на это время. Пусть даже этот ярлык запустится не за секунду, а за полторы или две.
С 10 до 11 ОК, может и не поломается ничего, а с ХР на 11?
Так-то теперь на 11 многие те-же старые игры без лютых плясок с бубном не запустишь, получается иногда парадоксальная ситуация, когда проще запустить старенькую игру под Винду, на Линуксе в Вайне.
Обратная совместимость это хорошо, но может быть уже пора все-таки сбросить весь этот груз хлама и сделать современную версию оси, в которой не делается попыток поддерживать старое барахло. Работает на новой системе - ну хорошо, повезло, не работает - увы.. Если эта штука будет работать шустрее и меньше жрать ресурсов, то своего потребителя она точно найдет.
Обратная совместимость это хорошо, но может быть уже пора все-таки сбросить весь этот груз хлама и сделать современную версию оси, в которой не делается попыток поддерживать старое барахло.
Может, и пора. Только кто будет спонсировать этот банкет? И кто будет покупать Windows, на которой не будет работать старый но нужный софт?
Так Windows вроде как, как раз и пытается внедрить "современные" UWP приложения, которые работают только в новых Windows и несовместимы со старыми.
Правда, лично мне они не нравятся по трем причинам:
Телефонно-планшетный дизайн с крупными шрифтами, большими промежутками и в целом малой плотностью информации. Я поэтому до сих пор не обновляюсь на Windows 11, потому что в этой версии эта гадость проникла даже в Проводник.
Установка куда-то в недра системы на диск C:, без возможности выбора. "Классические программы", в том случае если они занимают много места, например, игры, я обычно устанавливаю на диск D:, чтобы они лишнее место на системном диске не занимали. С "современными" так не получается.
Необходимость иметь интернет. Либо для установки из магазина, либо для первого запуска. Не люблю привязку к интернету.
Пытается внедрить "современные" UWP приложения.
Хорошо что пытается, только вот независимым разработчикам не хочется переписывать свои огромные пакеты приложений на других технологиях. Да и тот же MsOffice что-то никак не переходит в UWP.
Телефонно-планшетный дизайн с крупными шрифтами
Это всё вкусовщина из серии "все фломастеры на вкус и цвет разные", работать не мешает. Привыкание - пару дней максимум (проверено на себе, прошёл путь от 3.11 до 11).
Необходимость иметь интернет
Это тоже веяние времени. Для упоротых случаев есть обходы, а так, абсолютно пофигу. Надо выйти в интернет - пусть выходит. Take it easy.
Установка куда-то в недра системы на диск C:
Program Files и ProgramData? Это испокон веков "правильные" директории для установки пользовательских бинарей и данных соответственно. Если уж и переносить что-то на отдельный диск, то это всевозможные временные файлы, свопы и прочие кэши. Да и то не актуально в свете низкой (нулевой?) чувствительности ссд к фрагментации на уровне файлов.
Разбивать системный SSD на разделы приходится ради бекапов, чтобы не тащить в них терабайты игр, виртуалок и прочего мусора, который быстрее пересоздать, чем восстанавливать.
Зачем игру размером в несколько десятков гигабайт ставить на диск C:?
Мотивация здесь такая.
Систему нужно бекапить. Хотя бы потому, что SSD любят очень внезапно выходить из строя (в отличие от HDD, которые в большинстве случаев постепенно покрываются бед-блоками).
Единственный быстрый и надежный способ сделать бекап системы Windows - это сделать образ системного диска. Это не Linux, где возможен бекап и восстановление системы простым копированием файлов.
А теперь, собственно, вопрос. Зачем мне бекапить терабайт установленных игрушек, которые легко переустановить? Место на NAS не резиновое, плюс бекап будет делаться очень долго по времени.
Поэтому я , например, использую разделение на диск C: и диск D:.
На диске C: - система и пользовательские данные, размер диска 120 ГБ. Все это бекапится.
На диске D: - размер диска от 1 ТБ и выше, тут данные, которые занимают много места, но их не жалко потерять. Игры, папка Downloads, также всякие кэши по возможности.
И вот тут возникают лучи ненависти в сторону тех поделок, которые умеют устанавливаться исключительно на диск C:. Особенно раздражает писк последнего времени, когда программы устанавливаются даже не в C:\Program Files, а прямо в профиль пользователя в AppData.
Вы не учитываете, что затраты (временные и финансовые), которые необходимо потратить на это, непропорционально велики по сравнению с прибылью, которую компания сможет извлечь из этого. Вдобавок, рост потребности в ресурсах стимулирует рынок железа. Все в выгоде. И как вообще продавать эту вашу оптимизацию - непонятно. Я вот прям представляю, как маркетологи говорят "наша ос стала в 2 раза быстрее по сравнению с предыдущей версией", а рядовому потребителю мягко говоря все равно. Ибо он уже давно купил достаточно мощное железо, чтобы на замечать разницы между условно 1.и 0.5 секундами задержки. А те, кто сидит на старом железе, новую ос не факт что могут поставить, ибо набор команд процессора может уже не поддерживаться, нет secure boot и прочих улучшений, без которых винда ну никак не запустится) Вы мыслите с точки зрения потребителя и только в целях экономии железа, а интересы компании совсем не рассматриваете.
Я просто хорошо помню времена Винмобайла, тогда тоже много кто говорил что Майкрософту точно надо что-то делать со своей ОСью, потому что в плане интерфейса она странная и неюзабельная из коробки (кстати в плане производительности она была очень даже неплоха). И многие так-же писали что Майкрософту нет смысла вкладываться в это, потому что никакой прибыли это не принесет.. Жизнь показала, что МС упустили огромный рынок смартфонов, потому что Апл и Гугл все-таки вложились и сделали ОС для мобильных.
Это беда всех пакетных дистров, каждый выпуск может быть разный набор софта. Менее болезненно это на роллинг-дистрибутивах, типа арча или манжаро - там изменения наступают более плавно, и релизы не приносят столько много изменений. Но общая беда и тех и других, по сравнению с виндой - иерархия зависимостей: в винде можно держать несколько версий библиотеки, каждая под свой софт, а в этих дистрибутивах так сделать не получится. Если вдруг в системе оказываются программы, которые зависят сразу от двух-трех версий библиотеки, а такое иногда бывает, обязательно что-то ломается. Выходят из ситуации пока костылями типа флатпак, изолируя сам софт и все его зависимости в контейнерах, но это тоже не очень хорошее решение. Вот и получается что везде свои плюсы и минусы, везде свои особенности.
Одна из главных проблем OpenSource в том, что во многих случаях разработчик пишет код, как художник - "а я так вижу". Для другого разработчика такое видение можно хотя бы понять, если не принять. А вот для обычного смертного такое видение является тайной за семью печатями. Отсюда множественные жалобы пользователей на субъективно нелогичное поведение приложений и интуитивно (опять субъективно) непонятный интерфейс.
Возьмём ещё для примера vim. Он шикарен, быстр и удобен. Но только не для пользователя, которому текстовый редактор нужен раз в год, для того чтобы поправить конфиг в соответствии с найденными в интернете рекомендациями. Но потребовалось добрых два десятка лет, для того, чтобы не он стоял по умолчанию в большинстве дистрибутивов, а, например, куда более понятный для пользователя nano.
А как реагируют разработчики на feature requests на github обычных пользователей - сами знаете. Как это сделать имеющимися средствами - напишут. Могут ещё предложить самому патч написать. Но не станут добавлять то, самим неудобно или непривычно.
Много ли Вы видели PR, где, кроме разработчика указан ещё дизайнер-постановщик и тестировщик? Последний часто даёт весьма разумные рекомендации по эргономике и интуитивности интерфейса. В 99% - разработчик делает всё. И, как следствие, результат не редко оказывается нагромождением стереотипов и привычек одного конкретного индивидуума, преследующего свои конкретные субъективные цели.
Я ни в коем случае не против свободного ПО. Наоборот, я очередной раз напоминаю о проблеме, мешающей его развитию и которую на многих проектах до сих пор игнорируют.
Недостатки есть везде. Но для меня главная ценность OpenSource - это то, что можно найти репозитории, где есть более-менее пригодное к использованию решение практически любой задачи. Многие из таких репозиториев будут мертвы, обновляются раз в несколько лет, или вообще не обновляются. Но даже в таких случаях есть возможность форкнуть репозиторий, и по-быстрому дофиксить решение, довести до работоспособного состояния, и использовать, вместо того чтобы изобретать что-то с нуля. И с большой вероятностью кто-то все это уже сделал и где-то уже существует готовое к использованию решение, т.к. потребность в схожих инструментах обычно бывает сразу у множества людей. Причем инструменты эти разных уровней, от простеньких скриптов до более-менее серьезного софта - выбор есть часто. А еще есть возможность изучить код и доработать его, или перенести на более удобный язык/стек. Или присоединиться к какому-то популярному инструменту и внести в него те правки, которых не хватает, вместо того чтобы повторять функционал с нуля. И решения эти иногда уникальны: например как-то возникла потребность скачивать видеозаписи из IP-камеры, официального инструмента для этого не нашлось, не считая интеграций с сетевыми шарами, зато нашлись чьи-то наработки на гитхабе, которые буквально за 20 минут удалось запустить и использовать, т.е. OpenSource позволил решить задачу, решением которой не озаботился сам производитель.
А теперь перечитайте то, что написали и увидите прямое подтверждение моих слов. При таком подходе безразличны недостатки, которые не касаются личных потребностей. И интересны только свои конкретные субъективные цели.
Я не осуждаю. Индивидуализм и эгоизм пропагандируется элитами, как достоинство, а не недостаток. А социализированное мышление и коллективизм клеймится, как порождение враждебного коммунизма.
Но факт остается фактом. Для большинства потенциальных пользователей свободного ПО польза от такого подхода нулевая. Малейшие отклонения от личного сценария использования не тестируются, даже если они потенциально были предусмотрены в коде.
А есть какие-нибудь нормальные тесты? Гит был сделан в линуксе для линукса, плохой пример. ФПС в играх запущенных через неэмулятор тоже сомнительно, скорее всего этот неэмулятор просто фелонит, выполняет не всё что должен, рисует облака но без чаек или типа того.
Как насчет сравнить что-нибудь попроще и хорошо оптимизированное на всех платформах, 7зип например и sqlite benchmark.
А что такого в гите "для линукса", если там самая затратная часть чтение и запись файлов?
Слишком много чтения-записи, например, эффект от которых нивелируется особенностями кеширования в линуксе, но не в винде. Линукс более агрессивно кеширует дисковый вывод в памяти, например.
Это весьма общее свойство, чтобы говорить именно о гите.
Ну, остальные приложения не настолько требовательны к чтению-записи кучи файлов
Тут хорошее сравнение разницы в подходе, когда один вызов stat или mtime превращается в несколько сисколов в Windows, а кэши очищаются при закрытии хендла.
Этот тест проявляет достоинства ext4 и недостатки NTFS. К самим Linux и Windows он имеет косвенное отношение. Пожелай MS сделать в Windows поддержку ext4, то разницы уже не было бы.
Если в разрабатываемом приложении это учитывать, реализуя свою структуру внутри одного большого файла, то проблема решаема. Например, именно таким путем она решена в MS SQL.
Куда болезненней проблемы мультизадачности в Windows. Уже на 32 ядрах и 64 потоках, даже в приложении на родном для него C#, Windows начинает проигрывать Linux. На 384 потоках, парочке EPYC с 192 ядрами каждый, проигрывать уже более, чем в два раза. На Java картина аналогична.
Уж не знаю, в чем там причины, но свыше сотни нитей в одном приложении под Windows смысла уже не имеют. Чего не скажешь о Linux, где и тысяча нитей в одном приложении достаточно эффективны.
про организацию потоков вынь могу немного рассказать.
ms была выбрана следующая концепция: на уровне обычного пользователя потоки в процессе переключаются не быстрее 16мс. т.е. если вам надо каждую миллисекунду че-то проверять, на обычном потоке без спец. ухищрений это сделать не получится. но технические варианты что делать -есть. отсюда и эффективное кол-во потоков процесса = 1сек/0.016с=62,5 шт. т.е. другими словами, если вы сделаете 63 и более потока в процессе винды, то весь цикл переключения всех потоков займет более 1 секунды. в этой связи, делать 1000 потоков в вынь - смысла никакого.
внутри ядра и драйверах скорость переключения потоков -другая, там уже речь идет о микросекундах.
сделано так ввиду того, что ms поощряет дробление логики в компоненты уровня ОС (напр. com+), каждый из которых является отдельным процессом со своими условными 62 потоками на 1 ядро проца.
например, есть задача сделать нейросеть таким образом, чтобы часть ее узлов обрабатывалась своим потоком. что делают в линухе? просто тупо запускают условную тысячу потоков и делят между ними узлы.
ровно также можно сделать на вынь, но эффективность -вы сами видите. надо делать по-другому: создавать com+ компонент, запускать тучу этих компонентов(а по-сути, процессов) и каждый из них будет запускать не более 62 потока. потоки разных процессов могут работать параллельно за счет того, что в ядре происходит переключение (между процессами) в 1000 раз быстрее.
т.о. подобную задачу в вынь нужно решать не тупым переносом исходного кода, а принципиально иначе.
вот, собственно, почему в синтетических тестах вынь проигрывает линуху. потому что адаптировать и перекопилировать исходный код линуха под вынь - это архитектурная ошибка в вынь. и программисты линуха этого тупо не понимают.
потоки в процессе переключаются
А при чем тут переключение потоков? Я же сталкиваюсь не с переключением, а с обслуживанием ядром ОС системных вызовов из нитей, каждой из которых уже предоставлен свой аппаратный поток на ядре CPU. Чем больше у меня в коде асинхронных обращений к ОС - тем сильней деградирует ядро Windows, по сравнению с ядром Linux.
создавать com+ компонент
Вообще не взлетает. Больше 32 ядер или 64 потоков утилизировать не может. В итоге пришлось пилить виртуалки по 32 ядра для Rail-тариф сервер, функционирующий именно на COM+ компонентах. То есть, на одном и том же 384 ядерном сервере 12 виртуалок реально показывают десятикратно большую производительность, чем одна. А если поднять Windows напрямую на этих 384 ядрах, то, хоть убейся, производительность оказывается почти в три раза ниже, чем суммарно у этих 12 виртуалок с 32 ядрами и 64 потоками.
Отсюда уже давно и безуспешно просим СТМ переходить на Linux, а параллельно прорабатываем вопрос собственной разработки.
P.S. Если бы все было так просто, то в TOP-500 суперкомпьютеров уже хотя бы один на Windows затесался.
Зачем для 64 процессоров делать 1000 потоков? Почему не сделать 64 и пусть шуршат на всю катушку без лишних переключений? Да, Windows иначе работает с потоками, но это просто надо учитывать в разработке (в общем-то, так всегда и везде).
пруфа, конечно же, не будет
Подойдем к вопросу проще. Найдите хотя бы одну Windows среди ТОП-500 суперкомпьютеров. Причина та же самая.
Еще недавно, когда даже 32 ядра были роскошью, эта проблема вообще не стояла. Сейчас, когда даже на десктопе доступны 64 ядра и 128 потоков, проблема стала заметной. В ближайшем будущем, когда типовой сервер станет поддерживать аппаратно свыше тысячи потоков, не решив эту проблему MS потеряет серверный рынок.
Найдите хотя бы одну Windows среди ТОП-500 суперкомпьютеров
А точно не потому что винда просит лицензию за каждый проц? И на супер компьютере это может стоить очень дорого. Но я допускаю что проблема не только в этом)
И при желании, нет абсолютно никаких проблем выжрать хоть тыщу ядер на винде, было бы желание.
Тут кроме желания нужно ещё и умение. В системном API Windows поддержка более 64 ядер реализована через процессорные группы. Старые API (Get/SetProcessAffinity и Get/SetThread Affinity) ограничены 64 ядрами чисто из-за формата параметров. Соответственно, приложение, чтобы использовать >64 ядер, должно уметь с этими процессорными группами работать. По крайней мере так было, судя по документации, до Windows Server 2022: про него было объявлено что по умолчанию потоки приложения создаются на процессорах во всех группах, а раньше, вроде бы, все потоки по умолчанию создавались в рамках одной группы. К лучшему или к худшему это изменение - не скажу: через процессорные группы реализована ещё и поддержка NUMA (а в наше время каждый физический процессор - это минимум один отдельный узел NUMA), а поток, попавший не на тот узел, будет обращаться к своей памяти в разы медленнее.
PS Если вам захочется подискутировать насчет суперкомпьютеров, то прочитайте комментарий от того же автора, которому вы только что ответили: этот комментарий даст вам ответ (на самом деле - давно известный) на вопрос почему нет Windows на суперкомпьютерах.
PPS Я в здешней священной войне, как я написал выше, решил в этот раз не участвовать, так что по существу этой войны мне отвечать не надо.
Но если нужны ссылки на документацию по упомянутым API (вдруг сами найти не можете) - поделюсь. Заодно попутно могу поделиться кое-чем из документации уже на .NET на указанную тему (там тоже все не просто, кстати - вплоть до того, что некоторые параметры конфигурации в Linux и Windows имеют разный формат - и там для .NET 8 заявлено аналогичное изменение).
Даже если вы как разработчик компонента принимаете внешний патч, это злит вашего менеджера (из-за необходимости поддерживать этот патч и оправдывать незапланированное изменение дизайна), злит отдел тестирования (они должны убедиться, что изменение ничего не сломает, а вы только накинули им работы), а также злит менеджера проекта (из-за изменения графика разработки вследствие принятия патча). В итоге нет никаких стимулов принимать изменения, внесённые извне.
Да-да, это же не опенсорс, в котором принося патч с улучшением вы сталкиваетесь с тем, что никто не собирается его мержить, потому что он не соотвествует "духу разработки", и обещанием ну когда-нибудь потом дописать этот функционал.
народ тут акселерация системы виндовс, а они обсуждают bsod вешь вполне очевидная кроме первой.
как так можно ускорить систему что фпс игр 1,5х 2х раза вырастает, походу скоро на простом видяхе уровень 3060ти можно догнать.
ускорение винды локально или с помощью внешних систем виндовс азура ?
те проблемы, что перечислил автор- это не столько проблема windows, сколько проблема управления очень сложным программным продуктом.
давайте вспомним, как обновляется ядро линуха: модификация идет к Торвальду и только он решает, что войдет в ядро, а что нет. т.е. несмотря на вездесущий continuous integration, апрувит все-равно один чел. так не везде, но думаете от хорошей жизни торвальд этим занялся? или или не в курсе СI, полагаете?
возможно ли что-то подобное с вынь? определенно, нет. вынь определенно сложнее любого линуха по следующим причинам:
графическая подсистема вынь встоена в ядро, в линухе - это просто оболочки вне ядра. соответственно, разработчик оболочек - другой. отсюда в линухе почти нет конкурирующих команд разработки. они уже свои форки понаделали и развивают их кто в лес, кто по дрова отдельно друг от друга.
вынь в обязательном порядке содержит пользовательские компоненты уровня ОС - com/dcom/com+/activex/старые ole, которые экспортируют в ОС свое апи и импортируют чужое, в т.ч. таких же рядом лежащих компонентов. это апи имеет платформенный стандарт и описывается в tlb библиотеках, которые идут в паре с компонентом. и этот апи не имеет отношения к winap или сервисам вынь (они могут использовать несколько таких компонетов). никакого подобного механизма(пользовательские объекты на уровне ОС), и тем более, реализаций под него в линухах нет, имхо.
наличие объектных компонентов уровня ОС привело вынь к механизму интеграции оных в о внутреннюю безопасность вынь. т.е. компонент может запуститься по желанию стороннего кода согласно своих настроек, например, под учеткой админа, или вызывающего юзера или еще кого. и компонент будучи админом, может временами "прикидываться" юзером, чтобы внутренние механизмы безопасности сами разгребали, что доступно этому юзеру, а что нет. это очень глубокая интеграция.
обильное наличие внутренних сервисов на этих компонентах - вот причина проблем стабильности винды. совершенно понятно, что команда, которая делает iis не будет заниматься ms sql или сервисом выпуска сертификата. а оформлять любое функциональное решение в com/com+ - это требование ms и внутри компании оно четко соблюдается. отсюда - много команд, но механизмы ОС одни и те же (безопасность, доступ к файлам, памяти и пр.).
в качестве еще одного доказательства приведу пример того, что ms в считанные месяцы смогло включить внутрь вынь клон линуха. при этом, в отличие от виртуальных машин, линух видит родной диск вынь и даже пытается взаимодействовать с безопасностью вынь. т.е. это показывает, что вынь "проглотила" линух и не почти заметила этого.
также не согласен с идеей о том, что в линухе патчи способствуют исключительно стабильности и производительности. автор совершенно упустил из виду факты целенаправленного встраивания разных зловредов в исходный код открытых ОС. и мотивация здесь может быть совершенно иной: от желания любым способом "засветится" в качестве разработчика такого кода, до сомнительных решений в виде "закладок" на будущее.
стимул принимать внешние разработки для команд ms- есть. у каждой команды есть mvp и он не достижим без таких внешних вливаний. грубо говоря, релиз собственного модуля не выйдет в срок, если ранее было согласовано добавление внешнего кода. определенно, это злит всех. но нельзя сказать, что команда старается игнорировать такие вливания. наоборот, они там орут "давайте быстрее".
решение о mvp в вынь принимают руководители, а не программисты, как в линухе. т.о. руководители и программисты видят ценность своих продуктов по-разному. и это не имеет никакого отношения к продвижению в компании. "я реализую пару интересных проектов и меня подвинут на позицию рук. департамента" - это так не работает в коммерческих структурах. а работает следующее: чел отлично справляется на месте, вот он пусть и дальше этим же занимается.
Дело в том, что в Microsoft отдельные группы разработки «владеют» отдельными компонентами системы, и обычно они открыто враждебны к внешним патчам. Даже если вы как разработчик компонента принимаете внешний патч, это злит вашего менеджера (из-за необходимости поддерживать этот патч и оправдывать незапланированное изменение дизайна), злит отдел тестирования (они должны убедиться, что изменение ничего не сломает, а вы только накинули им работы), а также злит менеджера проекта (из-за изменения графика разработки вследствие принятия патча). В итоге нет никаких стимулов принимать изменения, внесённые извне.
Ну что тут сказать? Разработчики (вернее менеджеры) Microsoft идиоты!
В MS ещё проблема обязательств по поддержке. Если что-то плохое пролезет в продакшен, то придётся отдуваться от тысяч (и более) пользователей, которые будут заявлять, что раз заплатили за лицензию и техподдержку, то пусть им помогут ASAP. Естественно, менеджерам лишний риск и головняк не нужен, особенно когда он влияет на продажи и прочие финансовые вещи.
В линухе же в большинстве случаев "absolutely no warranty". Что-то сломалась при обновлении? Чувак, это твои проблемы.
Если в мире опенсорса это открытый процесс, который несёт пользу и улучшает систему, то в мире корпоративного ПО зачастую изменения вносятся по причинам эгоизма, желания продвижения по карьерной лестнице, славы и т. д. Всё это ведёт к деградации продукта.
Объективность на высоте
Если в мире опенсорса это открытый процесс, который несёт пользу и улучшает систему, то в мире корпоративного ПО зачастую изменения вносятся по причинам эгоизма, желания продвижения по карьерной лестнице, славы и т. д. Всё это ведёт к деградации продукта.
Вот он как выглядит юношеский максимализм во плоти. Уже после этого абзаца можно поставить объективность всей статьи под сомнение. И задуматься а стоит ли тратить время на ее чтение. Мне как пользователю линукса поселение 7 лет и любящей эту систему, даже как то стыдно что в наших рядах есть такие не адекватные фанбои.
Google и другие конкуренты постоянно переманивают самых умных и талантливых сотрудников. Происходит отток талантливых кадров. Microsoft вынуждена нанимать на их место студентов прямо из колледжа.
Вот тут прям заплакал
Если Linux, то только тот дистрибутив в котором есть полная поддержка шрифтов, на эти бесплатные дистрибутивы с ужасным рендерингом шрифтов смотреть, плохо становится. В Windows так же не полная поддержка шрифтов.
Мне одному статья показалась бессвязным набором разнотипных и разнонаправленных утверждений?
Почему Windows настолько медленнее Linux. Расползание фич