Здравствуйте, Философ, Вы писали:
Ф>Ч0 вы от неё все так кипятком ссыте?
Ф>Вот я, например — Windows-программер, и если бы не это обстоятельство,
Вопрос не в бровь, а в глаз. У меня мак уже года 4, брал, чтобы кросс-платформ писать , ну и из интереса. Так и не нашел в нем ничего такого, чтобы назвать его по удобству/юзабилити/свистелкам лучше той же семерки. Скажем так, на винде у меня две основные проги, Хром и Визуал Студия, которая меня кормит. Даже если отбросить возможность кодить в студии, вот какие минусы для меня в Макоси:
— Панель задач и переключение между задачами. Это какой то адский ад. Окна перекрывают друг друга, чтобы вернуться к предыдущему приложению, надо напрячь зрение и найти нужную иконку, которыми перегружена панель. Ок, продвинутые юзеры знают как делать аналог Alt+Tab (я тоже), но то ли дело в винде в один клик
— Сочетания клавиш. Переименование файлов по Enter, Карл! И таких неочевидных моментов достаточно, чтобы забыть про скорость работы, а тупорыло кликать мышкой, даже чтобы вырезать/вставить. Виндузятнику все это шаманство выучить — вагон времени.
— Зачем скажите целый зоопарк приложений постоянно перед глазами? Я в жизни не запускал календарь, сафари, почту, photoboost и всякую ересь. Все удалить чтоли оттуда?
— Средства разработки. Кодить под XCode, после Visual Studio кажется мазохизмом. Имхо конечно. А больше то и выбрать особо не с чего.
— За каждый чих нужно платить. Элементарный диктофон — 10$
— Finder. Explorer лучше. Всем.
— TextEdit сохраняет в своей кодировке, что потом в винде кракозяблы. Ну и \n, вместо \r\n. Надо ставить Sublime хотя. А в Вин хватает блокнота.
— Самое главное: Приложения. Игры.
Вот не нужно мне сейчас кросс-платформа никакого, и мак мне не нужен. Пишу только с него из хрома, пока Винда ставиться.
Здравствуйте, Cyberax, Вы писали:
C>Вот не надо бредить. Под Виндой контейнеры работают через виртуалку, а значит быстрее могут работать, только если виртуалка занимается читингом (например, игнорирует барьеры при работе с диском).
Ну значит она так же читерит под родной ОС.
Тут просто надо понимать принцип организации дров в Win Server и Win10 и как работают HyperV-дрова в линухах. Там линухи вообще "умывают руки", когда работают под гипервизором, бо памятью и нагрузкой процессоров управляет гипервизор, а дрова блочных устройств садятся на самый возможный верхний логический уровень. Никакими DMA гостевые ОСи не занимаются, бог с тобой. ))
Ты уже забыл, что ле, как MS в 2012-м году создала свою клон-ветку RedHat, по-жесткому занималась разработкой непосредственно ядра и дров Linux, а потом тупо отдала наработки обратно в RedHat и с тех пор всякие CentOS и SUSE просто порхают под HyperV.
Или не так давно MS провернула такой же фокус с убунтой, запуская её прямо из виндов. Умора как есть. Enjoy.
Как это всё работает — я же говорил как, по-сути все процессы всех ОС равноправны перед гипервизором. И если ОС "умывает руки", то зачем она вообще нужна? Т.е., речь должна идти о процессах и их окружениях, где ОС — это только набор сервисов для приложений.
Собсно, докер показал, что виртуализировать ОС нет смысла, что на деле-то требуется виртуализировать окружение.
В этом месте медитировать до посинения.
C>>>Я в Амазоне работаю, если что. V>>И как один твой Амазон повлияет на статистику? )) C>Он один больше, чем все остальные облачные провайдеры вместе взятые.
Опять эта твоя гипертрофированность.
V>>Я же не написал, что их под KVM нет вообще, я написал, что в сегменте выше 1000 железных узлов согласно сухой статистики Hyper-V давно и прочно в лидерах. C>LOL. Я знаю большинство крупных кластеров — Hyper-V там нет и близко.
Значит так знаешь. Общаешься только с братьями по разуму, типа Google Cloud Engine.
C>>>Ну вот я и смотрю на весь набор фич. HyperV — это приблуда для венды для запуска WinXP в режиме эмуляции, с красивой консолькой для детей, не освоивших CLI. V>>Я рядом так и написал, что тебя тянет сравнивать набор утилит под технологию, а не саму технологию, ы-ы-ы. C>А самая технолигя — ровно слизана с Xen, примерно 15-летней давности. Нынешний Xen за это время дорос до realtime и high-reliability.
Технология слизана с IBM 370.
C>>>KVM — это промышленная система для разворачивания крупномасштабных сетей в миллионы узлов. V>>Э, нет, KVM — это система виртуализации. C>Ага, и оно самая продвинутая.
Ты сейчас хвалишь некий набор инструментария-плагинов под эту технологию. Т.е. так и не понял сути моего замечания.
V>>Спокойно работающий виртуальный узел переезжает на другое железо "по-горячему". Т.е. нарастил себе железо в кластер и перегнал на него работающие виртуальные узлы, сбалансировав нагрузку. V>>Такую фичу в KVM уже сделали или как? Еще пару лет назад ругали за отсутствие такого же гладкого переезда в рантайме. C>Такая фича была в Xen с 2004-го, в KVM с 2008-го.
Я спрашивал о гладком переезде.
Вот только что проверил — нет, еще в KVM этой фичи нет и пока даже не предвидится.
Всё еще виртуалка сначала суспендится, а потом переезжает, только так. Время паузы составляет несколько секунд.
Бггг... так и на VirtualBox можно... Фигле там — засуспендил, скопировал, продолжил. Детсад, первая четверть.
C>Нынешний state-of-the-art — это запуск виртуалки на параллельных узлах для обеспечения защиты от аппаратных сбоев.
KVM тут не при чём.
За кластеризацию отвечает софт на стороне виртуалки, он может даже и не знать, что работает под виртуалкой (зависит от конкретного софта).
V>>Еще в прошлом году KVM ругали за недостаточные ср-ва по управлению питанием. И тут ты такой выскакиваешь и говоришь, что в KVM с управлением питанием лучше. Из какого пальца ты это насасываешь? Ты можешь сделать сухое сравнение этого вопроса с Hyper-V или тупо варишься в своём соку? C>Где ругали?
В интернет обзорах. В KVM получаются дорогие вычисления в пересчёте на ватты — перерасход порядка 66% в сравнении в виндами. Собсно, Linux исторически ругают по этому вопросу.
А где ты знания по Hyper-V черпаешь?
На сегодня нет ни одной другой операционки, где бы ACPI была настолько тщательно окучена, как в виндах.
Собсно, MS и стоит в числе главных за разработкой этой технологии.
Похоже, ты опять демонстрируешь свой гипертрофированный подход: наверняка прочитал об одном из последних обновлений Linux, где что-то немного улучшилось насчёт питания (угу, пару драйверов обновили, и теперь линуха стали видеть ACPI-Интерфейс еще у парочки конкретных железяк, у которых раньше тупо игнорили), и вот ты торопишься поделиться новостью: "В KVM самое лучшее управление питанием!!!". Мде-с...
Со стороны всё вместе смотрится убого, сорри. И такая ситуация в самих Линухах, и как ты знатно перегибаешь тут.
В общем, хуже с управлением питанием чем в Linux, нет нигде. Это вопрос драйверов, ес-но, где Linux болеет этой болезнью от рождения. Даже у Андроид и Tizen свои прикладные сервисы на этот счёт, бо родные линуховые — увы, увы. Поищи, как там Tizen вынужден изворачиваться на эту тему — у него своя ветка ядра уже нарисовывается. Я бы поставил тут фейспалм, но это уже скорее грустно, чем весело.
C>>>Эта орхитектура была придумана в Xen в 2003-м году. И была выброшена за ненадобностью в KVM. V>>Эта архитектура была придумана за 40 лет до них, если что. И выброшена не была. C>Была. В Линуксе сейчас лучший в мире планировщик задач и менеджер памяти, масштабирующиеся на любое железо.
И опять у тебя приступ "гипер". ))
Суперкомьютеры НАСА работают под Windows Server, почему-то.
А вот суперкомпьютеры для студентов во всяких ВУЗ-ах — те на линухах, тут не сомневайся.
Происходящие в реалтайм ядерные реакции в реакторах и токамаках сегодня управляются виндами.
Зато моделирующие всякие расчёты и прочие ненастоящие "эксперименты на кончике карандаша" — сплошь отданы на откуп линуховым "вычислительным кластерам".
Железо крупнейших американских, европейских и японских бирж, (взять тот же NASDAQ) — везде оно работает под Windows Server.
А железо мелких азиатских бирж — Линуха. Правда, железо пары крупных, типа гонгконгской и сингапурской тоже винды, кста.
Лично-хостируемая почта крупнейших мировых предприятий и организаций, включая специальные службы — всё это крутится исключительно на виндовых серваках и там даже заикаться не стоит, чтобы пролезть с линухами. Тебе просто в лицо поржут вот так: ха-ха-ха. Еще и у виска покрутят. ))
Да, я в курсе, что уже два года как Амазон пытается пролезть на рынок корпоративной почты, но пока что лишь мизинец просунула на тот рынок, который давно окучен GMail for business, т.е. для мелких контор, которым не стрёмно хранить свою переписку на чужом "облаке".
Да куда ни плюнь в более менее серьезное применение, где нельзя ошибиться и где большие деньги — везде виндовые серваки.
А вот предоставлять облачные услуги неисчислимым толпам лохов для хостинга их порносайтов — тут да, тут KVM впереди планеты всей. Это бесспорно.
C>Потому его и легко можно использовать в качестве гипервизора, процессы KVM интегрируются с SELinux, маршрутизацией и т.д. При желании стандартными средствами делается и passthrough для железа — IOMMU в Линуксе является естественными расширением обычного MMU.
Мы уже обсуждали этот вопрос в прошлый раз, у тебя память короткая.
Во-первых, IOMMU в виндах от рождения, RTFM.
Во-вторых, сценарии IOMMU бывают весьма специфическими-ограниченными. Т.е. вся прелесть виртуализации в таких сценариях резко теряется.
C>Но в Винде планировщик задач и менеджер памяти не меняли фундаментально с незапамятных времён
Бггг...
Я же тебя просил уже провести ПРОСТОЙ эксперимент из десятка строчек — просто по кругу погонять пакеты снала м/у линуховыми, потом м/у виндовыми машинами. И тупо самому через любой сниффер убедиться в том, что задержки в линухах на точно таком же железе получаются примерно в 2.5 раза больше. Да какие проблемы, вообще, взять да посмотреть самому ХОТЯ БЫ РАЗ?
C>и они лишь чуть лучше гуана мамонта. Потому MS и пришлось создать, фактически, ещё одно ядро для гипервизора, которое может нормально планировать задачи. Причём это полноценное ядро — с драйверами и защитой памяти.
RTFM, RTFM. )))))
Ничего для гипервизора не потребовалось, кроме создания VMBus — разделения дров на клиентский и микроядерный интерфейс.
Причем, для каждого класса устройств это разделение выполнено уникальным образом (и тому есть веские причины).
В этом и состоит весь прикол Hyper-V, что не смотря на всякие там картиночки с кружочками и квадратиками, показывающие несколько логических слоёв (якобы несколько), по факту мы имеем обычное ядро исполнения уровня 0 и обычные виндовые (самые лучшие на сегодня де-факто) дрова устройств, доступ к которым имеют все хостящиеся операцинки с подержкой доступа к VMB.
Я же писал тебе уже — материнская партиция точно так же обращается к дровам через VMB, как любые другие партиции. Всей разницы, что материнская партиция управляет процессом загрузки этих драйверов, как это делает обычная винда, которая тоже с бааальшим таким опережением над всеми остальными умеет находить и подставлять нужные дрова, ы-ы-ы тысячу раз.
Кароч, там всё намного проще, чем ты даже можешь себе представить.
А насчёт "давно не обновлялся планировщик" — не позорился бы. На всех углах полно инфы, это не секретная ни разу информация.
К тому же, к планировщику линухов до сих пор есть претензии, прикинь? ))
Вот у меня например! Ты ведь можешь самостоятельно провести еще один простой тест в линухах — в одном потоке подавай сигнал на семафор, а другой поток путь будет в этот момент в блокирующем ожидании на этом семафоре (спячке). Просто замерь статистику задержки пробуждения. Потом сделай так же в современных windows и охреней от разницы задержки в опять в 2-3 раза не в пользу линухов. В этом месте у тебя у самого должны возникнуть претензии и желание посмотреть в исходники — да что за хрень-то??? Вот, займись полезным делом...
А пока мест тут говорить особо не о чем. Я не знаю, как ты умудрился невесть что себе в голове накрутить.
V>>Не зря именно в линухах сетевые картейки гоняют в юзер-левельном режиме, что эту архаичность по-другому не переплюнуть. C>Да-да. Скажи это haproxy.
Мы ведь эту тему тоже уже обсуждали год назад (или сколько там уже прошло времени?).
Тыкать в меня веб-проксей, когда речь шла о микросекундах... В общем, я уже устал стебаться над тобой.
V>>Т.е., сформулировать не можешь? V>>Ну напомни, хотя бы, а то прям заинтриговал. )) C>Поищи поиском.
Поискал, не нашел.
Ты меня заинтриговал лишь потому, что обработка сигналов (конкретней — обработка звука) — это моё хобби всю мою сознательную жизнь. Фактически единственное постоянное хобби. Т.е. мне действительно любопытно — что и у кого там могло случиться не так-то?
Здравствуйте, Cyberax, Вы писали:
C>>>Так benchmark'и делают только идиоты. V>>Такие тесты делают лишь циничные практики, не страдающие ангажированностью. C>Нет, я про методологию. См. на графики и дикие скачки на них.
Скачки в начале тестов, на это можешь не смотреть, смотри на устоявшуюся "полку".
Там вполне информативны строки насчет более 90% результатов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У них сейчас все в таком состоянии. А через два года еще и объявляется безнадежно устаревшим. Венда стала линуксем.
Здравствуйте, TechL, Вы писали:
TL>- Панель задач и переключение между задачами. Это какой то адский ад. Окна перекрывают друг друга, чтобы вернуться к предыдущему приложению, надо напрячь зрение и найти нужную иконку, которыми перегружена панель. Ок, продвинутые юзеры знают как делать аналог Alt+Tab (я тоже), но то ли дело в винде в один клик
Таки да, и все попытки решить эту проблему в виде "показать все окошки в виде небольших превьюшек" это припарки. Проблему надо решать в корне, а на такой редизайн сложно пойти.
TL>- Зачем скажите целый зоопарк приложений постоянно перед глазами? Я в жизни не запускал календарь, сафари, почту, photoboost и всякую ересь. Все удалить чтоли оттуда?
Просто удали.
TL>- Средства разработки. Кодить под XCode, после Visual Studio кажется мазохизмом.
Да, мазохизм и более того — каменный век.
Но, надо отметить таки меееееееедленно меняется к лучшему. Я изнутри их пихаю, и за год они таки кое что починили. Глядишь, к 2020му XCode наконец научится делать то, что я имел в вижуалке в 2008м году.
TL>- Finder. Explorer лучше. Всем.
Как по мне так что одно что другое то ещё говно.
TL>- TextEdit сохраняет в своей кодировке, что потом в винде кракозяблы.
Вроде ж в UTF8 сохраняет, не?
TL>Ну и \n, вместо \r\n.
Не, тут как по мне так \r\n надо изничтожить.
Здравствуйте, vdimas, Вы писали:
V>По-факту на KVM сидят облака средней размерности, до тысячи узлов, тут по статистике KVM обходит Hyper-V по числу инсталляций, дооо. V>А вот когда выше — резко сливает согласно сухой статистике.
А теперь возвращаемся в реальность — в ажуре 1000 узлов это максимум что доступно. Причем это только для готовых, специально оттюненых образов. А для кастомных образозв лимит вообще 100 узлов.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>По-факту на KVM сидят облака средней размерности, до тысячи узлов, тут по статистике KVM обходит Hyper-V по числу инсталляций, дооо. V>>А вот когда выше — резко сливает согласно сухой статистике. НС>А теперь возвращаемся в реальность — в ажуре 1000 узлов это максимум что доступно.
Кому "доступно"? Это у MS всего 1000 машин всего на ажуре? ))
Из консоли Hyper-V или через АПИ, или скриптами PS можно управлять произвольным кол-вом хостов, никаких физических ограничений тут нет, разумеется. Так же нет ограничений на кол-во управляемых узлов у какого-нить менеджера виртуалок, типа https://www.5nine.ru — эта управляющая система обслуживает произвольное кол-во кластеров.
==============
Можно посмотреть на конкурентов — "вообще все" машины Google Cloud или Amazon тоже не составляют единый кластер, ес-но. Сами кластеры раскиданы географически и количество узлов в каждом отдельном кластере обычно невелико — единицы/десятки машин всего, намного реже сотни (таких мало). Т.е. даже если в некоем дата-центре дофига машин, физически они поделены на кучу относительно независимых кластеров. При том, что каждый их кластер — это то самое полноценное облако.
Клиентов просто раскидывают по разным кластерам в зависимости от заказанной ими "ёмкости" услуги и загруженности кластеров. Я думаю, что у MS вряд ли схема сильно отличается.
Здравствуйте, vdimas, Вы писали:
V>Кому "доступно"? Это у MS всего 1000 машин всего на ажуре? ))
При чем тут МС? В одном кластере не более 1000 машин. А сколько там всего машин насрать, они друг от друга не зависят.
V>Можно посмотреть на конкурентов — "вообще все" машины Google Cloud или Amazon тоже не составляют единый кластер, ес-но.
Тогда о чем ты вообще ведешь речь в контексте разговора? Какая связь между гипервизором и общим количеством машин во всех датацентрах на планете?
V>Клиентов просто раскидывают по разным кластерам в зависимости от заказанной ими "ёмкости" услуги и загруженности кластеров. Я думаю, что у MS вряд ли схема сильно отличается.
МС ничего самостоятельно не раскидывает. Датацентр ты выбираешь сам (за исключением геораспределенных хранилищ). Внутри датацентра есть некоторое количество независимых по электричеству и сети сегментов. Вот тут МС может сам раскинуть, ориентируясь на fault domains, а можно и самому задать через availability set.
Здравствуйте, Mystic Artifact, Вы писали:
P>>А когда там было "так" со шрифтами? MA> Никогда не было.
Ага, никогда не было и вот опять. Это как ведроид, который совсем не тормозит, но в каждом релизе заявляется, что проблему с тормозами наконец окончательно побороли.
MA> Есть проблемы с тем что есть несколько способов это настраивать, и не каждое приложение подхватит твои настройки.
Это вообще одна из основных проблем линухов — миллион альтернатив одного и тоже. Даже по буферу обмена договорится не смогли. Как только выходим за пределы ядра — начинается тотальный разброд и шатание.
Здравствуйте, Философ, Вы писали:
Ф>Даже хуже: оно там разъезжалось всё, потому что софт ни о каких шрифтах и картинках не знал / не знает, кроме тех, которые в него программист захардкодил, только это не про разрешение а про настраиваемые размеры шрифтов и DPI.
Оно раньше разъезжалось. Поэтому для старого софта придумали режим масштабирования. После чего стали жаловаться на мыло.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Кому "доступно"? Это у MS всего 1000 машин всего на ажуре? )) НС>При чем тут МС?
Да я пока пытаюсь выяснить, о каких ограничениях речь? ))
Ажур — это готовая платформа для торговли облачными ресурсами. Если тебе не надо торговать ресурсами, то тебе не нужен Ажур и его ограничения (я хз с чем они связаны). Все крупные датацентры на сегодня являются вручную обслуживаемыми уникальными архитектурами.
Просто инфа, о чём идёт речь:
— в среднеразмерном по современным меркам дата-центре живут десятки тысяч физических узлов, соединённых в одну общую сетку, в крупных — сотни тысяч;
— нет абсолютно никакой проблемы управлять этим парком под Server 2016 Hyper-V или любой другой современной гипервизорной технологией;
— внутри этой физической сетки можно создавать практически бесконечное кол-во реальных и виртуальных кластеров;
НС>В одном кластере не более 1000 машин. А сколько там всего машин насрать, они друг от друга не зависят.
Это тоже странная цифра.
Если речь о failover cluster, то согласно доке на Server 2012 были ограничения в несколько десятков узлов, на Server 2016 — единицы сотен. И это ОЧЕНЬ круто. Для сравнения:
the maximum number of hosts in a single Red Hat Enterprise Linux HA Cluster is 16, and that any Cluster with 8 or more hosts will need an architecture review from Red Hat to determine supportability.
Просто надо понимать, что сами эти узлы могут быть "страшные" — например, в сотню физических процов на узел, плюс "бесконечная" считай оперативная и дисковая память в пересчёте тоже на узел. ))
Указанные выше ограничения никому не мешают:
— любой датацентр — это не статическая архитектура, в любой момент времени берутся любые свободные узлы и динамически объединяются в какой-нить failover cluster, требуемой величины;
— наиболее популярные размеры кластеров для целей хостинга веба и БД — 2..4 физические машины, а более 90% современного отказоустойчивого интернета вообще живёт на кластерах размером в две физические машинки;
— в среднеразмерном датацентре одновременно живут порядка десятка тысяч таких кластеров, а сама конфигурация этих кластеров (конкретные входящие в них ноды) находится в состоянии эдакого "динамического равновесия", т.е. упавшие узлы отлетают, вместо них на горячую к кластеру подключают новые узлы (бо в средних и больших датацентрах ноды порой падают ежедевно, иногда до десятков нод в день — это их рабочий ежедневный сценарий).
Т.е., еще раз, медленно — абсолютно никаких ограничений на кол-во узлов Hyper-V, объединённых в общую сеть и управляемых с некоего одного "менеджера", нет и быть не может. Датацентр может быть фактически произвольных размеров.
V>>Можно посмотреть на конкурентов — "вообще все" машины Google Cloud или Amazon тоже не составляют единый кластер, ес-но. НС>Тогда о чем ты вообще ведешь речь в контексте разговора?
О суммарных размерах "облака" — я же сказал сразу.
Попадалась как-то на глаза статистика, что на крупных предприятиях, располагающих собственными относительно большими вычислительными парками (если предприятие не торгует выч.мощщами, а для себя) популярность Hyper-V выше, чем популярность KVM.
Т.е. получается такая любопытная закономерность: чем меньше собственный парк машин, тем популярнее KVM. Такая зависимость мне показалось забавной, её я и хотел озвучить.
НС>МС ничего самостоятельно не раскидывает. Датацентр ты выбираешь сам (за исключением геораспределенных хранилищ). Внутри датацентра есть некоторое количество независимых по электричеству и сети сегментов. Вот тут МС может сам раскинуть, ориентируясь на fault domains, а можно и самому задать через availability set.
Ну я не спец по ажуру. В любом случае каждая такая система уникальна. Т.е. по большому счёту мне совершенно не интересно как там в какой-то конкретной из них делается. Тем более, что сегодня так, завтра сделают эдак и т.д. В этой области всё меняется слишком быстро. ))
Например, у датацентров бирж свои особенности — там независимые инструменты раскидываются по независимым кластерам. Поэтому, когда подключаешься к бирже, то порой подключаешься одновременно к десяткам фидов. Вот как это работает в реальной жизни.
(И я как раз по своей ежедневной работе разрабатываю/тюню подобные "массовые" UDP- и TCP- подключения).
Здравствуйте, Ночной Смотрящий, Вы писали:
P>>>А когда там было "так" со шрифтами? MA>> Никогда не было. НС>Ага, никогда не было и вот опять. Это как ведроид, который совсем не тормозит, но в каждом релизе заявляется, что проблему с тормозами наконец окончательно побороли.
Я знаю, что запоздало. Но, имхо с ведроидом проблемы то исключительно в железе. Для комфортной работы ведроида 6 нужно всего лишь какой-нибиудь A8 и 3GB RAM. Если ты про анимэшки — то мне, лично, как юзеру ведроидов — абсолютно на это пофиг, так они у меня всё равно не более чем читалки почты/новостей/и внезапно?! звонилки! Всё. Остальное — мне лично — пофигу.
Я понимаю, что другим людям подавай что-то другое.
Но, извините. Вот вышел несколько месяцев назад скайп под ведроид. Он же ж тормозит на топовом железе после короткой переписки, и кто виноват? Опять ведроид? Или всё таки ото нубло что его выпустило? При том ещё поломали совместимость с кучей 4.Х устроств, хотя заявили отмену только 2.Х.
Для меня, лично, все эти *обощенные* наезды на платформы — откровенно говоря неочевидны. Я не говорю — что ведроид — это круто и т.п. Просто, твои аналогии это как меч, занесённый над двумя щитами. Можешь им долбить до потери пульса, но ты их не пробьешь.
Меня недавно попросили посмотреть, почему не стартует игрушка на винде. Хех. Мешал какой-то левый битый шрифт. *WALL*
Опять повторюсь: меня абсолютно устраивает рендеринг в Windows и современных Linux. Последние предпочтительнее Ubuntu — т.к. там пропатчено кое-чего. Но, "лучшая" в удобности у меня была установка Arch, и без их патчей обошелся. В реальности сам шрифт важнее всех этих прибамбасов. Тем более сейчас, где нет искусственных ограничений.
MA>> Есть проблемы с тем что есть несколько способов это настраивать, и не каждое приложение подхватит твои настройки. НС>Это вообще одна из основных проблем линухов — миллион альтернатив одного и тоже. Даже по буферу обмена договорится не смогли. Как только выходим за пределы ядра — начинается тотальный разброд и шатание.
Я с этим полностью согласен. Кстати говоря, тут ты прямо в глаз. Меня буфер обмена бесит в первую очередь. Тут настроил и между виртуалками обмениваешься свободно, а тут... между родными приложениями не можешь. Согласен полностью.
А ещё меня выбесило в... 2015-м году по моему: только Linux Mint мог нормально переключать раскладку по ALT+SHIFT. Только он!!! Жесть!
Каждый дистрибутив имел ессно подобную опцию, но срабатывание этих клавиш... о как много в этом! Оказывается это исскуство.
Я раньше всегда перенастраивал венду на что-то другое. А потом я просто привык к стандартной. А оказалось что линукс далеко не каждый можно настроить так, как оно работает в винде. В 2015-м Gnome3 к примеру это делал так, что если ты быстро печатаешь/быстро переключаешься — то тебе светят только матюки. Я не понимаю КАК можно этого достичь, т.к. я отлично помню контроллер клавиатуры, который посылает команды абсолютно чётко. Даже таймауты не нужны что бы понять что было нажато ALT+SHIFT или SHIFT+ALT. Ну и тем более чего там тупить если было нажато ALT+SHIFT+X (любая буква) — ведь — команды "key up" приходят потом.
Не. Только Linux Mint это нормально понимал. Остальные, включая Ubuntu — курили в тряпу. Увы-увы. Обидно, что такие мелочи не покрыты.
Опять, повторюсь, может быть щас "полегчало", но — я почему обратил внимание — этот вопрос, имхо, следовало бы закрыть лет 10-15 назад.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Но, имхо с ведроидом проблемы то исключительно в железе. Для комфортной работы ведроида 6 нужно всего лишь какой-нибиудь A8 и 3GB RAM.
У меня всего 1.3 ГГц (4 ядра) на 2ГБ памяти.
Тормозов не замечено от слова ВООБЩЕ.
Здравствуйте, DenisCh, Вы писали:
MA>> Но, имхо с ведроидом проблемы то исключительно в железе. Для комфортной работы ведроида 6 нужно всего лишь какой-нибиудь A8 и 3GB RAM. DC>У меня всего 1.3 ГГц (4 ядра) на 2ГБ памяти. DC>Тормозов не замечено от слова ВООБЩЕ.
Ну RAM важнее герцев. Скажем у меня сейчас аппарат с 4GB RAM — 7 ведроид — никаких тормозов. И у тебя — никаких тормозов. Но зависит ведь от числа приложений (в большей степени от их кривизны — ведь соизмеримые приложения по функционалу часто кушают в трехкратном размере). Поэтому конечно — кому-то хватает. Кому-то нет. Когда-то мне и 512MB хватало и ведроид был 2.3. И никаких FB на телефоне не было. А сейчас как ни крути 5 мессенджеров, — от браузера хочется что бы "как на десктопе". И телефоны как минимум 3-х летней давности (я имею ввиду не топы) — вполне это позволяют. А на сегодня — так и подавно.
Ответ запоздалый — "взвешенный".
Ну а фанатикам iPhone X — стоит только взять за 1000 рублей в аренду коробочку от него чтобы с сэлфится... Круто же.
PS: Ну т.е. я имел ввиду — да какая разница чо там — всё равно вопрос в железе — либо она тянет ваши приложения — либо нет. "Тянет" — это когда хотя бы ещё 250Мб RAM остаются свободные — иначе тормоза обеспечены в любом случае.
Здравствуйте, zverjuga, Вы писали:
Z>в макоси чтобы сделать скриншот, достаточно нажать комбинацию кнопок ctrl+shift+4 и выделить нужный тебе кусок экрана. и скриншот автоматически сохраняется на рабочем столе
Дичь какая-то ))
В виндах для вызова любой программы можно назначить комбинацию клавиш:
Тут стоит только включить воображение, качнуть сотни свистелок под винды, назначить им клавиши быстрого доступа, и тебе совсем нечем будет крыть. ))
Здравствуйте, IID, Вы писали:
IID>Один из моих любимых: поток это не поток, а процесс.
задача
юниха же от рождения имели пакетный планировщик
IID>А процесс это не процесс, а группа потоков процессов.
процесс — это группа задач
V>>Windows — пытается быть всем для всех. IID>Линукс до версии 2.6 вообще был однозадачным, с блокированием шедулера при вызове сервисов ОС.
Линукс был всегда пакетным и на некоторых классах задач поэтому эффективней, бо шедулер проще
Ему добавили реалтаймовости сугубо для GUI
IID>Windows же значительно более современная система. Не прошло и 30 лет — и линукс начинает напоминать Windows NT, вводя технологии, которые у последней были с рождения. Например софтверные приоритеты в ядре ОС, для нормальной многозадачности. Вместо всяких прибитых гвоздями костылей, типа принудительного разрезания обработчика прерываний на 2 части, half и bottom.
Бесполезно сравнивать различные алгоритмы планировщика без привязки к конкретным сценариям.
В линухах можно настраивать не только приоритеты (как в виндах) но и выбирать алгоритмы шедуллинга для конкретного процесса.
А таковые алгоритмы для GUI-программы и нагруженного веб-сервака сильно разные.
В виндах же алгоритм шедуллинга настраивается лишь для всей системы целиком.
С другой стороны, это тоже где-то правильно, бо нефик гамать на серваке. ))
Здравствуйте, Философ, Вы писали:
Ф>А что такого в MacOS?
Да собственно ничего такого.
На том же самом железе графика в Windows работает в разы быстрее. А MacBook так вообще под Windows был сделан похоже.
Есть у меня ощущение что MacOS скоро претерпит радикальные изменения. Ибо там все устарело на лет 10 как.
Например CoreGraphics это по факту GDI+, прости хоспидя.
Здравствуйте, vdimas, Вы писали:
V>В линухах можно настраивать не только приоритеты (как в виндах) но и выбирать алгоритмы шедуллинга для конкретного процесса.
For processes scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0).
Поддержка приоритетов есть только в экзотических и примитивных SCHED_FIFO (без квантования ваще) и его слегка улучшенной версии SCHED_RR (с квантованием):
SCHED_FIFO is a simple scheduling algorithm without time slicing.
...
A SCHED_FIFO process runs until either it is blocked by an I/O request, it is preempted by a higher priority process, or it calls sched_yield.
...
SCHED_RR is a simple enhancement of SCHED_FIFO. Everything described above for SCHED_FIFO also applies to SCHED_RR, except that each process is only allowed to run for a maximum time quantum.
V>А таковые алгоритмы для GUI-программы и нагруженного веб-сервака сильно разные.
Win-планировщик испокон веков умеет бустить GUI (выделил) и ожидание на объектах синхронизации:
Each thread has a dynamic priority. This is the priority the scheduler uses to determine which thread to execute. Initially, a thread's dynamic priority is the same as its base priority. The system can boost and lower the dynamic priority, to ensure that it is responsive and that no threads are starved for processor time. The system does not boost the priority of threads with a base priority level between 16 and 31. Only threads with a base priority between 0 and 15 receive dynamic priority boosts.
The system boosts the dynamic priority of a thread to enhance its responsiveness as follows.
When a process that uses NORMAL_PRIORITY_CLASS is brought to the foreground, the scheduler boosts the priority class of the process associated with the foreground window, so that it is greater than or equal to the priority class of any background processes. The priority class returns to its original setting when the process is no longer in the foreground. When a window receives input, such as timer messages, mouse messages, or keyboard input, the scheduler boosts the priority of the thread that owns the window.
When the wait conditions for a blocked thread are satisfied, the scheduler boosts the priority of the thread. For example, when a wait operation associated with disk or keyboard I/O finishes, the thread receives a priority boost.
You can disable the priority-boosting feature by calling the SetProcessPriorityBoost or SetThreadPriorityBoost function. To determine whether this feature has been disabled, call the GetProcessPriorityBoost or GetThreadPriorityBoost function.
After raising a thread's dynamic priority, the scheduler reduces that priority by one level each time the thread completes a time slice, until the thread drops back to its base priority. A thread's dynamic priority is never less than its base priority.
Здравствуйте, IID, Вы писали:
IID>Linux как раз не поддерживает приоритеты: IID>Поддержка приоритетов есть только в .. SCHED_FIFO и ... SCHED_RR
Забавно наблюдать общение человека с самим собой.
V>>А таковые алгоритмы для GUI-программы и нагруженного веб-сервака сильно разные. IID>Win-планировщик испокон веков умеет бустить GUI (выделил) и ожидание на объектах синхронизации:
