Здравствуйте, Pauel, Вы писали:
P>На счет отзывчивости лялиха — я шота за неделю получил слишком много примеров обратного, когда морозится минутами, потом вдруг прорывает на секундочку, и эти секундочки надо ловить, что бы переключиться в другой терминал и сделать рестарт.
С таким вообще никогда не сталкивался. Максимум — когда память кончилась и начало жрать своп — плеер в браузере стал заикаться.
P>Пудозреваю, здесь, как и везде, в лялихе большой рандом. Теоретически — настроить можно, практически — это требует экстремальной квалификации.
Я думаю, у тебя что-то с совместимостью железа. Максимум, что я настраивал — это выкручивал энергоэффективность в максимум, чтобы вентиляторы не включало.
Здравствуйте, vsb, Вы писали:
vsb>Все эти тонны приложений используют qt/gtk или мало кому нужны. И qt и gtk на wayland портированы.
Портирован только GTK3.
Вернее, он был переделан для возможности использовать виртуальный бэкенд,в числе которых может быть и Wayland.
По итогу GTK3 в аналогичных сценариях проигрывает GTK2 в эффективности.
vsb>Поэтому масштаб проблемы преувеличен, имхо.
Разумеется, масштаб проблем преувеличен, потому что речь всегда идёт о достаточности.
Линуха вполне себе достаточная система на сегодня для юзания.
Но мы-то проводим сравнительный обзор? ))
vsb>Подозреваю, что уже сегодня все популярные приложения работают на wayland без всяких эмуляторов.
Неа, многие используют XWayland, т.е. иксы поверх Wayland, что опять же даёт понижение общей эффективности.
В общем, у Линухов настолько проклятое (с ударением на первом слоге) легаси, что аукаться будет еще много десятилетий.
Просто обрати внимание, насколько ловко Андроид, а до этого Mac OSX отказались от всего этого юниксового графического легаси г-на, использовав собственные графические подсистемы.
Здравствуйте, vsb, Вы писали:
vsb>Это было в один день с OpenVPN. Я думал, что проблема с сервером, уже всё перерыл, пока не настроил клиента на рядом стоящем линуксе.
В виндах есть встроенный VPN-сервер, сторонний не нужен.
Было бы интересно, чтобы ты попробовал виндовый и сравнил.
Кто его знает, может проблема с OpenVPN, что тот вылизывался под линухового клиента?
Здравствуйте, Pauel, Вы писали:
P>Не знаю, что там ты мерял, мой сервис при запуске под виндой стабильно держит меньше реквестов, чем запущеный на линуксе, от 20 до 50% если пейлоад 500кб P>Если же пейлоад около 1кб, то в виндовс в районе 1000 реквестов и дальше ну никак не лезет, в линуксе — 3000...6000
Твой сервис на чём? На ноде? ))
P>Собственно, медицинский факт, Линукс доминирует на сервере, и по этой, и по ряду других причин.
Он доминирует из-за бесплатности.
А нода твоя кривая, я уже тебе показывал, что она работает в режиме реактора, в то время как в виндах родной режим — это режим проактора.
Конкретно нода работает не в родном режиме асинхронного IO в Windows, вот и весь ответ.
Де-факто, на том же железе Windows держит больше соединений и имеет большую пропускную способность, чем Linux.
Просто надо использовать IOCP ровно так, как он и задумывался — получать в колбэке не сигналы о доступности данных в сокете (как оно есть в Linux), а уже полученные в поданном буфере данные.
Аналогично в новом АПИ RIO, быстрее пока мест ничего не придумали.
Никто не мешает портировать ноду в Windows глубже, кстате.
Похоже, они ограничились самым поверхностным портированием, эмулировав на Windows механику Linux, бгг...
Здравствуйте, student__, Вы писали:
__>Здравствуйте, vsb, Вы писали: vsb>>Ну SELinux — тут спорно, но тем не менее он куда серьёзней и комплексней подходит к организации безопасности, хоть и настраивать его очень сложно.
__>Кому он нужен кроме АНБ/ЦРУ/Госдепа?
Здравствуйте, vdimas, Вы писали:
P>>Если же пейлоад около 1кб, то в виндовс в районе 1000 реквестов и дальше ну никак не лезет, в линуксе — 3000...6000
V>Твоё сервис на чём? На ноде? ))
Нода, джава, дотнет — без разницы.
V>А нода твоя кривая, я уже тебе показывал, что она работает в режиме реактора
Я помню, что ты так и не понял, как работает асинхронщина. У ноды время отклика стабильно меньше джавы и дотнета, идентичные реализации того же сервиса. Пока в дотнете запрос сидит очереди, в ноде он уже обработался.
Единственное, где сливает нода, это вычисления. Вот здесь действительно всё плохо. Там, где вычислений минимум, и пейлоад небольшой(рендеринг большого джсон это трудные вычисления), нода вполне себе конкурирует и с дотнетом, и с джавой.
Скажем, мой сериализатор одата протокола обгоняет и джавовский, и дотнетный. Но вот на больших пейлоадах он морозит эвент луп. Есть варианты для оптимизации, к сожалению, они очень непростые.
V>Де-факто, на том же железе Windows держит больше соединений и имеет большую пропускную способность, чем Linux.
Чего оно там держит, совершенно не интересно, если сервисы этим воспользоваться не могут.
Отлично, начинаем пороть твою закладку, благо там удобная для порки неадекватная личность. ))
Как известно, ядро WinNT было содрано с VAX VMS, где не было слоя виртуальных файловых систем.
В то время как WinNT вышел сразу с виртуальной файловой системой.
Но Microsoft в своей бесконечной мудрости решили пойти своим путём и построить файловую систему на основе модели слоёных драйверов.
Хоть калачом назови, только в печь не клади. ))
Разумеется, виртуальность FS обеспечивается соотв. драйверами, что в Windows, что в Linux, что везде.
Построили. Не работает. Точнее работает очень медленно — в сотни раз медленнее по сравнению с Novell NetWare.
Откровенная ложь.
У нас в лабе в 1994-м были файловые серваки NetWare и Windows NT.
Разница быстродействия составляла менее двух раз.
Напомню, что NetWare использовала кооперативную многозадачность, была незащищённой, дырявой как голландский сыр.
Данные по сети могли могли потеряться, сетевые файлы портились при неудачном одновременном доступе.
В отличие от, NT была тру-многозадачной, хорошо защищённой системой, с корректным одновременным доступом к файлам по сети, с журналированной файловой системой + инструментами для восстановления.
Это были разные весовые категории.
Это как сравнивать быстродействие FoxPro и Oracle на той же самой технике.
Первый надирал задницу второму в простейших сценариях, выглядел бледно в более сложных и совсем сдувался, когда речь заходила об огромном кол-ве сценариев и требований, которые в FoxPro тупо не реализованы.
Еще был файловой сервак с каким-то из юнихов (не помню точно что за юниха, но на иксы я впервые посмотрел именно тогда) — показывали наихудшее быстродействие из всей троицы.
Да и вообще на той же технике юниха знатно тормозили, хотя на меня произвело впечатление работа удалённого текстового терминала, вот там всё просто "летало" по меркам того времени.
Назвали это Fast I/O.
Но так как заглянуть как это сделано в НОРМАЛЬНЫХ системах ума у них не хватило, то для реализации Fast I/O драйверу ФС приходится напрямую взаимодействовать с менеджером кэша.
Нет, не это.
Была разработана концепция настраиваемого кеширования/синхронизации данных в зависимости от особенностей устройства FS.
Разумеется, в такой системе некоторые вызовы "прошивают" слой кеша насквозь, и?
Зато появляется шанс развивать алгоритмы шедуллинга операций кеширования/синхронизации под разные политики хранения, и они с этим в итоге справились великолепно.
То есть, вместо красивой схемы
Эта "красивая схема" сводит с ума жёсткие диски в простейших сценариях, потому что слишком абстрагированные абстракции всегда слабы.
И, главное, ничего нельзя поделать без тотального пересмотра архитектуры... только переезжать на SSD. ))
Не зря все линуховые облака живут на SSD, а жёсткие диски используют как эдакий "прозрачный бэкап длительного хранения", замена tar-ам на магнитных лентах.
Естественно, с переусложнёнными схемами блокировки и семантикой работы.
Тут вообще нубство/непрофессионализм, бо на одноядерных тогдашних машинах блокировки были, считай, бесплатными, т.к. реализовывались не через дорогущий CAS, а через дешевые разрешение/запрещение прерываний с установкой флагов. Плюс отсутствие механизма когерентности м/у ядрами, плюс управление сразу передавалось другому потоку в одноядерной машине, без холостых спин-вращений, как оно есть сейчас.
В общем, блокировки стали тяжелы только в многоядерных системах.
Сайберикса несёт, как обычно. ))
Что вызывает то, что NTFS фрагментируется чуть менее, чем мгновенно — даже в условиях, где этого легко избежать.
Очередное шикарнейшее нубство.
Термин "фрагментация" в NTFS стал означать вовсе не то же самое, что в FAT16/FAT32.
NTFS преднамеренно допускала разбиение данных на относительно крупные "островки" — кластеры.
Да-да, именно так, как это происходит в malloc, потому что уплотнять все данные друг к дружке показало себя плохой идеей при активном их CRUD.
И вот свинья, не разобравшись в апельсинах, сравнивает их с желудями.
Fail'ы продолжаются. В NTFS добавили возможность монтирования FS на каталоги и символических ссылок (т.е. reparse points). Казалось бы, ну чего тут можно сделать неправильно, когда даже в Windows уже они были реализованы в Windows Services for Unix? Но Microsoft смог сделать это! Вместо хранения симлинков и информации о монтировании дисков в виде специальных файлов (в их объектной ФС, которая это умеет с рождения!) и реализации их на уровне VFS, они СНОВА были реализованы на уровне конкретных драйверов (http://msdn.microsoft.com/en-us/library/ms794497.aspx) с помощью специальных IOCTL'ей.
Тут опять махровое нубство, бо речь идёт не о символьной ссылке на файл, а об directory junction — эффективнейшей штуке NTFS.
Ну ещё есть очень душевные fail'ы как Change Journal — NTFS умеет писать лог всех изменений. Причём он включается совершенно незаметно для пользователя, и никак понять нельзя, что он работает.
Без комментариев. ))
Сайберикс, конечно, никогда не заботился о потере своего лица, эдакий радикальный пох-ист.
Старый FAT32 уже никуда не годиться. Что сделал MS? Правильно, exFAT — консервативное расширение существующего FATа. Унылое на 100% и точно так же неприспособленное для SSD, как и старый FAT
Опять надо бы без комментариев. ))
В общем, именно из-за отсутствия надобности дефрагментации SSD, FAT64 показал себя максимально подходящим (экономным и шустрым) форматом для флешек, т.е. хранилищ относительно небольшого размера, где не предполагается активная 24х7 работа в режиме CRUD.
И да, в Linux тоже с удовольствием используют этот формат для флешек, ровно по той же причине — потому что NTFS, ext3, ext4 отжирают у флешки лишнее драгоценное пространство под внутренние нужды, где эти внутренние нужны заточены под другие сценарии.
Для сравнения, в Linux'е для работы с flash'ем реализован NilFS — http://www.nilfs.org/en/ , поддерживающий непрерывный snapshotting и другие вкусности
С такими друзьями линуху никаких врагов не надо.
NilFS не имеет к Linux никакого отношения.
Это независимый формат, который однажды был подержан в ядре Linux аж в 2009-м, когда флешки уже начинали терять свою актуальность.
Поезд уже ушёл... Надо было раньше...
В деле хранения фото/видео, передачи файлов и т.д. всё больше рулили сети (в т.ч. социальные), мессенжеры, почта и т.д., бо интернет уже был практически всегда и везде.
V_>Очень даже нет. Я припоминаю этот ник. Не помню о чем, но помню, что спор с тобой долгий, бессмысленный и занудный.
Факты любят достоверность, а логические выводы — точность.
V>>Или если не понял написанного — спроси подробности. V_>Это уж точно нет, я не могу так бездарно "закапывать" свое время.
Звиздеть зато бездарно можешь.
Испортил воздух — и убежал. ))
V_>Пользуйся Windows, раз у тебя диски с ума сходят, раз питончики и гейство тебе спать не дают. Мне то, что, наплевать же.
Я пользуюсь всем подряд, будучи при этом глубоко опечален количеством унаследованных косяков, что в архитектуре процов, что в архитектурах современных ОС.
С другой стороны, я понимаю причину наличия этих косяков — проклятое легаси.
Те решения в ПО, которые когда-то были наилучшими, перестают таковыми быть при смене архитектур и характеристик железа.
И у этого железа аналогичная болезнь совместимости.
Сама совместимость железа с г-ном мамонта нужна, опять же, исключительно для ПО!
Это мы, тупые программисты, тянем всю отрасль назад, показывая невозможность адаптации к изменяющемуся миру, хотя, по-задумке, сама идея программируемых устройств отталкивалась от целей достижения гибкости/изменяемости.
Но мы эту цель просрали, не справившись с легаси, не озаботившись заранее этим грузом.
Не оформили наш труд таким образом, чтобы он не протухал от малейших изменений архитектур/платформ/характеристик.
Сколько было написано кода и выкинуто?.. На триллионы долларов... ))
Сколько выкинуть жалко до сих пор, хотя давно пора? — на еще большие суммы.
Но ангажированная массовка всё еще с пеной у рта протестует против параметрического проектирования ПО, в т.ч. с привлечением визуальных ср-в, т.е. протестует против идеи зафиксировать результаты труда программиста таким образом, чтобы эти результаты не протухли и через 10 лет, и через 50. Чтобы однажды описаный алгоритм произвольной сложности мог быть воплощён в кодах огромного кол-ва платформ без переделок, с различной шириной типов данных, различными ограничениями, стратегиями и т.д. до бесконечности, бо параметризация и в Африке параметризация.
Плюс отрасль многократно себя дублирует, десятки тысяч программистов делают одно и тоже с косметической разницей, решают одну и ту же задачу, каждый в меру своей испорченности, и всё для того, чтобы этот код потом всё-равно протух.
Степень коллаборации в деле разработки современного ПО натурально удручает, хотя технических проблем давно никаких нет. Есть психологические проблемы "видения", есть ангажированность, нетерпимость, высокомерие и прочее такое, что к технической стороне дела не имеет никакого отношения.
Здравствуйте, Pauel, Вы писали:
V>>Твоё сервис на чём? На ноде? )) P>Нода, джава, дотнет — без разницы.
Разница есть, дотнет в виндах использует IOCP в асинхронщине в родном режиме проактора, а в линухах epoll в его режиме реактора.
Первая технология заруливает вторую.
V>>А нода твоя кривая, я уже тебе показывал, что она работает в режиме реактора P>Я помню, что ты так и не понял, как работает асинхронщина.
Ты тогда вообще мало чего понял. ))
P>У ноды время отклика стабильно меньше джавы и дотнета, идентичные реализации того же сервиса.
ЧТД, ты даже не понимаешь, о чём речь.
P>Пока в дотнете запрос сидит очереди, в ноде он уже обработался.
Прикольное у тебя самовнушение.
То-то тесты показывают обратное — нода сливает .net core как любитель профессиональному спортсмену, с разницей более двух раз.
И эти результаты еще до выхода 5-го дотнета, с которого .net core стал заметно шустрее в таких задачах.
И какая в опу "очередь", кстате?
Это у твоей ноды однопоточная очередь, в дотнете пул потоков.
P>Единственное, где сливает нода, это вычисления. Вот здесь действительно всё плохо. Там, где вычислений минимум, и пейлоад небольшой(рендеринг большого джсон это трудные вычисления), нода вполне себе конкурирует и с дотнетом, и с джавой.
Пока что нода сливает всем и везде, поэтому серьёзные приложухи с десятками тыщ коннектов ней не пишут.
И не будут писать никогда.
Это нишевое решение, со слабыми ср-вами масштабирования.
Разумеется, с накопленными ср-вами прямо сейчас нода неплоха для небольших и средних независимых сервисов, которые требуется быстро сляпать и запустить.
Но для чего-то более серьёзного...
P>Скажем, мой сериализатор одата протокола обгоняет и джавовский, и дотнетный.
Давай разумного размера спецификацию JSON и тестовые данные, я тебе на коленке сделаю решение на .net core в единицы строк через кодогенерацию на Roslyn — ты сильно удивишься, "я гарантирую это!" (С)
Удивишься как ничтожному кол-ву требуемых телодвижений, так и эффективности конечного результата, особенно если сделаю деплой в .Net Native, бо кодогенерённая сериализация не использует метаинформацию, упс? ))
Мне уже заранее сильно весело, если что...
P>Но вот на больших пейлоадах он морозит эвент луп. Есть варианты для оптимизации, к сожалению, они очень непростые.
Не надо использовать инструменты не по назначению.
Нода изначально позиционировала себя примерно как замена перлу в вебе, ни на что большее не замахивалась.
V>>Де-факто, на том же железе Windows держит больше соединений и имеет большую пропускную способность, чем Linux. P>Чего оно там держит, совершенно не интересно, если сервисы этим воспользоваться не могут.
Это твоя нода не может, которая никогда и не собиралась ничего "держать".
Если надо "держать" — есть соотв. технологии.
В общем, с тобой всё по-кругу, годы идут, а ничего не меняется. ))
Здравствуйте, student__, Вы писали:
__>если ты такое демиург, то ты должен был выучить хотя бы уроки первого класса по истории и знать, что "все — это файл" — филосифия, озвученная Эриком Реймондом, и к архитектуре современного *nix имеет мало отношения
Да плевать, кто на ком сидел и когда.
Речь о текущем фактическом положении дел.
Здравствуйте, smeeld, Вы писали:
B>>Но это всё равно бесполезно, линупс концептуально — говно мамонта на принципах из 60-ых. Сегодня нужны совсем другие системы. S>Напиши правильную ОС
Здравствуйте, vdimas, Вы писали:
V>Разница есть, дотнет в виндах использует IOCP в асинхронщине в родном режиме проактора, а в линухах epoll в его режиме реактора. V>Первая технология заруливает вторую.
На замерах этого не видно — вот я тебе и пишу — линукс стабильно быстрее винды.
V>И какая в опу "очередь", кстате? V>Это у твоей ноды однопоточная очередь, в дотнете пул потоков.
А ты "специалист". "однопоточная очередь" В ноде тоже пул потоков, только оркестрируется из js-ного. Если у нас идет 100 коннектов, а ядер всего 8, то запросы будут большей частью висеть в очереди, ибо все ядра заняты, что в дотнете, что в ноде.
Но вот здесь нода работает несколько иначе, и время задержки меньше.
P>>Скажем, мой сериализатор одата протокола обгоняет и джавовский, и дотнетный.
V>Давай разумного размера спецификацию JSON и тестовые данные, я тебе на коленке сделаю решение на .net core в единицы строк через кодогенерацию на Roslyn — ты сильно удивишься, "я гарантирую это!" (С)
Легко — вся документация по одата протоколу открыта.
Да любой юникс или *bsd по многим критериям лучше линукса. И еще куча всяких академисеских поделий. Но промышленным стандартом де-факто стал именно линукс. Почему? Потому-что если сейчас встает задача что-то развернуть и что-то поднять, никто не побежит искать совершеннейшую ОСь, а возьмут что-то стандартное. Это как поезд, если разогнался, то его так просто не остановишь. Как и почему линукс стал стандартом? Это ОСь которая вполне тянула все, в том числе и самое тяжелое, но с которым было меньше всего гемора, с вендорлоками и прочей доступностью. Так течении последних 20-ти лет на линукс все и перебежали.
Здравствуйте, smeeld, Вы писали:
S>Как и почему линукс стал стандартом? Это ОСь которая вполне тянула все, в том числе и самое тяжелое, но с которым было меньше всего гемора, с вендорлоками и прочей доступностью.
Да, ключевое это.
Linux стал центром притяжения мирового опенсорса.
Здравствуйте, Pauel, Вы писали:
V>>Разница есть, дотнет в виндах использует IOCP в асинхронщине в родном режиме проактора, а в линухах epoll в его режиме реактора. V>>Первая технология заруливает вторую. P>На замерах этого не видно — вот я тебе и пишу — линукс стабильно быстрее винды.
На замерах ноды?
Продолжаешь троллить...
V>>И какая в опу "очередь", кстате? V>>Это у твоей ноды однопоточная очередь, в дотнете пул потоков. P>А ты "специалист". "однопоточная очередь" В ноде тоже пул потоков, только оркестрируется из js-ного.
В ноде пул потоков IO, но события перенаправляются в одну JS-очередь.
Мы это уже разбирали не раз, заканчивай наводить тень на плетень. ))
P>Если у нас идет 100 коннектов, а ядер всего 8, то запросы будут большей частью висеть в очереди, ибо все ядра заняты, что в дотнете, что в ноде.
Да не будут в Windows висеть, в этом и прелесть.
Все эти запросы в проакторе могут обрабатывать одновременно, хоть тысячу их, независимо от кол-ва потоков и ядер.
На пальцах, как работает реактор (допустим, по чтению):
— система ждёт готовности одного или нескольких сокетов;
— по готовности возвращает список готовых сокетов, обслуживающий код в цикле вызывает прикладной колбэк для каждого готового сокета;
— прикладной колбэк, в свою очередь, вызывает ф-ию чтения из сокета в некий буфер; если данные некоторого пакета еще не пришли целиком — возврат на начало.
Этот режим используется нодой в линухах и виндах.
Как работает проактор:
— в систему подаётся для чтения один или несколько буферов для приёма данных, ждём принятия этих данных;
— унутре ядра ОС происходят аппаратные прерывания от картеек по мере поступления физических пакетов из сети, данные из этих пакетов раскидываются по буферам; то бишь, многие тысячи коннектов могут принимать данные "одновременно" прямо на уровне ядра, без промежуточного буферирования в буфере сокета;
— прикладной колбэк вызывается уже по готовности данных, то бишь, из прикладного колбэка не требуется опять вызывать ф-ии ядра по чтению данных.
Таким образом, вместо использования буфера сокета, используются прикладные буфера, куда сразу пишутся данные.
Буфер сокета тоже может быть, куда будут складывать те данные, которое приложение не успевает выгребать, но при правильной организации, прикладные буфера ничем не отличаются от внутренних, поэтому смысла во внутренних буферах немного, их можно отключить. В чём заключается "правильное использование буферов"? — в перекрывающемся (overlapped) IO. Пользовательский код может инициировать несколько операций IO с разными буферами, идеально будет 2-3 операции. Таким образом, пока текущие принятые данные обрабатываются приложением, ядро продолжает напихивать данными поданные буфера следующей инициированной операции. И вот так по кругу эти 2-3 операции крутятся, подставляя буфера для ядерного IO.
Именно через этот способ получается насытить данные 10-гигабитных картеек в Windows через одно соединение.
В Linux не получается никаким способом, они там в экспериментах насыщали десятком независимых соединений.
Вдогонку, замечание про ноду.
С т.з. АПИ IO, нода выступает для прикладного программиста проактором, то бишь, прикладной программист инициирует операцию чтения и получает колбэк с уже принятыми данными.
Мои замечания к ноде к тому, как это организовано унутре — через режим реактора, то бишь, происходит лишняя перекачка данных.
V>>Давай разумного размера спецификацию JSON и тестовые данные, я тебе на коленке сделаю решение на .net core в единицы строк через кодогенерацию на Roslyn — ты сильно удивишься, "я гарантирую это!" (С) P>Легко — вся документация по одата протоколу открыта.
Не нужен весь протокол, ткни меня в пару структур, на которых можно устроить замеры.
(ты-то делал по работе, а у меня тут факультатив)
И дай, плиз, соотв данные — ведь ты как-то замерял, чтобы делать выводы, что у тебя оно работает быстрее.
Предлагаю в этом вопросе чуток посотрудничать, разве тебе самому не интересно посмотреть/сравнить?
Ты ж сидел долго на дотнете, т.е. тебе должно быть как минимум любопытно.
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, Константин Б., Вы писали:
КБ>>Ну так в этом и вопрос. Почему разработчики убунты не воспользовались этими замечательными возможностями?
КБ>>Более того. Если мне в убунте понадобиться venv с другой версией питона — мне придется собирать этот питон из исходников. КБ>>Докер тут конечно тоже выручит, но по сравнению с виндой где я просто могу скачать и поставить столько версий питона сколько захочется — выглядит как-то кривовато. КБ>>Ну и "идеальная ОС для разработчика" на мой взгляд так себя вести не должна.
V_>Быстрый поиск:
V_>- https://medium.datadriveninvestor.com/how-to-install-and-manage-multiple-python-versions-on-linux-916990dabe4b
Здравствуйте, Буравчик, Вы писали:
КБ>>Вот на моем ноутбуке например в линуксе не работает звук. И сколько в логи не смотри, он не заработает.
Б>Что за дивное звуковое устройство?
