Comments 261
Может какое-то время и будет поддерживаться as is и с фиксами, но крупные нереализованные фичи вряд ли будут реализованы, увы (
Имеется подозрение что тупо не осилили
Проблема не в квалификации, а в том, что некоторые вещи из Linux не могут быть реализованы в Windows принципиально. Ввиду полного отсутствия хоть чего-то похожего.
Ломать винду ради линуха никто не будет. А лепить отдельные костыли под специфические вызовы… Рано или поздно приходит в голову "Да ну его… Давайте всё поставим на костыли, только одинаковые" — и появляется WSL2.
Собственно автор так и пишет, только другими словами.
PS. аналогично решено в macOS — все консольные приложения из brew/port вполне отлично работают после простой перекомпиляции; а для графических есть единый (тяжелый, но единый) костыль XQuarz.
налогично решено в macOS — все консольные приложения из brew/port вполне отлично работают после простой перекомпиляции
Разве что простые утилиты, которые в ядро не лезут. У макоси с линуксом общего только условный POSIX слой, который все равно имеет тонну несовместимости даже в простейших случаях. Утилиты так вообще совершенно разные порой. Взять какой-то нить htop — для макоси, как и для всех остальных ОС, свой слой совместимости, что неудивительно. POSIX дает доступ только к базовым функциям, а все внутренности ОС и устройств это mach прослойка и IOKit. Никакого proc же нет.
На уровне сисколов тоже расходятся
opensource.apple.com/source/xnu/xnu-6153.11.26/bsd/kern/syscalls.master.auto.html
github.com/freebsd/freebsd-src/blob/master/sys/sys/syscall.h
Да видно, что начинали с BSD, но дальше все полностью расходится. Даже базовые вещи вроде mmap не совпадают по номерам и, судя по всему, поведению. Все новые сисколы вообще разные. Плюс Apple как и MS не гарантируют совместимость на уровне сисколов, поэтому все приложения должны линковаться с libsystem_kernel.dylib и прочими.
А эмуляция у BSD сделана через реализацию сисколов линукса (и то, многие не реализованы), чего в макоси и в помине нет.
Заявление немного расходится с тем, что внутре у ней неонка, т.е FreeBSD, у которой с эмуляцией сис.вызовов Linux норм, даже акцентировано в статье
там ядро не Linux и не FreeBSD
от FreeBSD там только набор базовых утилит, тех, что в FreeBSD называются world
Полтора землекопа это как раз про автора статьи, который высосал из пальца какой-то потенциал администрирования винды тулзами линукса, для чего WSL никогда не позиционировался и никто не собирался двигать его в этом направлении.
Особенно, если вспомнить главную цель WSL — дать разработчикам, для которых винда родной инструмент (а это, на минуточку, 50% по опросам stackoverflow), простой способ билдить свои сорцы под линукс.
Я слышал о другой цели: перетащить разработчиков под Windows, которым объективно всё равно или почти всё равно под какой ОС разрабатывать (скриптовые кроссплатформенные языки прежде всего), предоставив им субъективно привычный CLI/TUI инструментарий для разработки и деплоя в Azure, пускай и на Linux инстансы
Для разработки удобнее, когда проект достаточно изолирован от основной системы, когда можно делать снэпшоты и если надо — переносить в контейнере на другой компьютер. Так что очень логично засунуть этого всё в ВМ, а не интегрировать напрямую в основную систему, нет?
Совсем не силен в powershell, поэтому стало интересно, как написать, например, простейшее:
cat file.txt | grep some-value >> file-to-append.txt
?
https://antjanus.com/blog/web-development-tutorials/how-to-grep-in-powershell/
Но грепать в виндовс лучше все-таки в git bash или в FAR/TotalCommander. Я вот под мак осью пользуюсь консолью а в винде Тотал Командером.
Так уж вышло, что в отличии от линукс, виндовс обычно идёт вместе с UI даже если это сервер — соответственно, «ручное администрирование» заточено под UI. Ну и да, PS оперирует объектами а не потоком символов как баш — из-за этого сложные скрипты писать проще (PS почти как .NET, только синтаксис кривоват), а вот интерактивно грепать сложнее. Справедливости ради, линукс консоль тоже не очень очевидная и требует знаний типичных команд, а также их аргументов на память.
В то время как для grep ещё и существует великолепная замена в виде ripgrep, который в некоторых сценариях работает в разы быстрее grep (потому что мультипоточный, умеет в SSE и другие оптимизации).
Get-Content file.txt | Select-String "some-value" | Out-File -Append file-to-append.txt;
Кто-то скажет, что еще не страшно. А потом начнется рекурсия, исключение файлов по маске… и точно станет куда страшнее юниксового аналога.
А потом начнется рекурсия, исключение файлов по маске… и точно станет куда страшнее юниксового аналога.
Или наоборот, когда речь зайдет об манипуляции уровня понятий/объектов в целом:
habr.com/ru/company/vdsina/blog/535214/#comment_22505466
PS оперирует объектами а не потоком символов как баш — из-за этого сложные скрипты писать проще
В статье вообще-то не про то что баш лучше или хуже, а про то что под WSL2 баш даже теоретически не видит объекты винды, а винда не видит объекты линукса (процессы, файлы, итп). А под WSL1 они друг друга видели, но поддерживать это оказалось сложно.
Он прекрасно работает и под 10 виндой, на рабочем ноуте, и на домашнем минте. Виртуалки просто можно копировать между системами.
У кого как насчёт потребления ресурсов.
У меня и людей из Microsoft с этим невесело и требуется постоянно лечить с помощью
echo 1 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/vm/compact_memory
Подробнее про жор памяти
https://devblogs.microsoft.com/commandline/memory-reclaim-in-the-windows-subsystem-for-linux-2/
Он запускается за пару секунд, висит в фоне незаметно
Я недавно в порядке экспериментов пробовал переползти с Linux на Винду, и обнаружил что при запуске любой WSL2 машины от памяти отъедается порядка 2 Гб. Даже если в ней единственный пустой баш запущен.
не требует постоянно тонны ресурсов, видит всю память и проц системы
По-моему так умела WSL1, а WSL2 — честная виртуалка со всеми плюсами и минусами, по сути то же что Virtualbox запущенный headless и с примонтированными в /mnt виндовыми дисками.
WSL2 машины от памяти отъедается порядка 2 Гб
У меня с автозапуском докер демона ест 1ГБ после запуска.
WSL2 — честная виртуалка со всеми плюсами и минусами, по сути то же что Virtualbox запущенный headless и с примонтированными в /mnt виндовыми дисками.
WSL2 работает несколько хитрее. Она видит весь проц. Она видит всю память, но от хоста она откусывается динамически. Диск тоже дефолтный динамический и размечен на весь хостовый диск. Думаю там и других отличий полно с учетом скорости запуска и интеграции. В общем, с точки зрения пользователя это совершенно не похоже на виртуалку.
В WSL2 полноценный Linux, так что там нет «диска», зато там есть точки монтирования, в том числе «диски» хост-системы тоже доступны. Но сам Linux при этом не работает поверх NTFS, у него своя файловая система.
И никто память на лету линукс хосту не убавляет. Линукс хост продолжает видеть столько памяти, сколько у хоста. Это hyperv, под которым это все работает, способен динамически выделять память гостю. В диспетчере задач можно наблюдать, сколько реально гость потребляет памяти.
Это hyperv, под которым это все работает, способен динамически выделять память гостю.
только у всех технологий виртуализации есть родовая болячка — наращивать память виртуалке они могут все, а вот отбирать назад — фигушки. В WSL2 как-то по-другому?
хост система
prod [root@monitoring chemist]# virsh setmem graylog.private.*** 15G
prod [root@monitoring chemist]# virsh setmem graylog.private.*** 16Gнепосредственно виртуалка
prod [chemist@graylog ~]$ free -m
total used free shared buff/cache available
Mem: 15980 4962 1052 1017 9966 9592
Swap: 0 0 0
prod [chemist@graylog ~]$ free -m
total used free shared buff/cache available
Mem: 14956 4961 201 1017 9793 8572
Swap: 0 0 0
prod [chemist@graylog ~]$ free -m
total used free shared buff/cache available
Mem: 15980 4963 1238 1017 9778 9594
Swap: 0 0 0Кого волнует, что это виртуалка?
Например, тех пользователей, кому приходится напрягаться с включением VT* в BIOS и у кого Hyper-V конфликтует с другими средствами виртуализации?
Ну, приходится выбирать между неработающей WSL1 и конфликтами с существующими виртуалками. Я для себя выбрал использовать гиперви и не париться.
Hyper-V конфликтует с другими средствами виртуализации?
Все нормальные средства вроде научились жить с ним бок о бок. virtualbox, vmware оба уже давно умеют использовать hyperv. Да и банально, раз уж так надо, то почему-то просто на сам hyperv не перейти.
Прикольно было ansible задачи выпонять в powershell просто через
docker run -it microsoft/ansible:latest ansible-playbook.... VS Code вроде имеет такую возможность прямо из интерфейеса запускать плейбуку через подобный вызов контейнера безо всяких Remote-SSH.
Хотя через Remote-WSL тоже весьма и весьма приятно много чего делать.
Бее того, он позволяет не только контейнеры запускать, но и одной галочкой целый Kubernetes.
Для девелопермента очень даже. И, мне кажется, эффективнее, чем запускать виртуалку с mikrok8s или чем-то подобным, выделяя вируталке фиксированный объем памяти…
Есть у него своя ниша.
Под Windows нет бинарника ансибла.
Ну, учитывая, что он строго говоря скрипт под python, а интерпретатор python 3.* есть под винду… то Ваше заявление в лучшем случае полуправда
К сожалению, я не умею запускать Ansible под Win без Cygwin. Если у вас получилось, буду рад, если поделитесь опытом.
Пока мне останется виртуалка с линуксом (полноценная или через WSL) либо докер контейнер.
Для времянки только
Ничего не виснет. Пробовал мигрировать с virtualbox на hyper-v — отказался из-за плохой поддержки старой windows xp, после очередного обновления, заставить гостевую систему видеть сетевые шары хоста стало невозможно.
Скажем так, большая часть озвученного не имеет никакого отношения к действительности.
WSL 1 основана не на подсистеме окружения (как на древнем слайде из Википедии), а на пико-процессах. Это совершенно иная реализация с точки зрения архитектуры. POSIX/Interix/SFU действительно были когда-то сделаны как подсистемы, но WSL 1 устроена попросту абсолютно иначе.
Касательно рассуждений о трансляции системных вызовов. Она частично присутствует. Некоторые эмулируются, некоторые пробрасываются через обёртки, а для некоторых (таких как fork), в ядро NT были внесены нативные реализации, которые LXSS дёргает напрямую. И об этом тоже прямо писалось в официальном блоге. Да, теперь NT умеет настоящий никсовый fork/exec, представьте себе. Так что «не умеет» — это не соответствует действительности. Умеет, ещё как, и уже достаточно давно.
Огорчает, что на некогда техническом ресурсе публикуются такие малограмотные спекуляции.
Вокруг микросервисы, околонулевые затраты на нити итп…
Может и ПОЗИКС туда же…
В мусорку истории.
Что именно в мусорку уйдёт — порешает рыночек своей невидимой ручкой. Пока же весь бум микросервисов основан именно на технологиях Linux с его POSIX-подходом, вон, даже в Windows вынуждены были его впилить для хотя бы приемлемой работы докера.
Разработчик, внезапно, на posix пофиг. Они работают в терминологии высокоуровневых библиотек и фреймворков. Вот проведите опыт и спросите у какого-нибудь фронтендера про posix и что это такое. Скорее всего ответ будет невнятным.
Суть претензии в том, что некоторые тут предлагают запретить этот самый fork, так как винда не осилила, а это по их мнению автоматически означает ненужность. Я при этом не обсуждаю, нужен ли fork на самом деле или нет, просто подчёркиваю, что такой ход мысли не является логически верным.
Справедливости ради, на современных системах fork + exec не делает битовую копию памяти (она клонируется лениво при доступе к ней). Но это и правда костыль, решаемый нормальным CreateProcess.
Если мне не изменяет память, то используется постраничный механизм Copy on Write, но это не про безопасность, а про производительность. Стэк, возможно, и правда копируется сразу, спорить не буду (нужно же куда-то результат fork сразу класть, правда). Я и согласен, что CreateProcess нужен, первый комментарий был чисто про то, что большая часть памяти не копируется при fork+exec на практике.
Справедливости ради, лучше знать тему, а не рекламировать свою некомпетентность.
В особенности назначение и подробности обработки ядром флажка CLONE_VFORK, которому уже более 20 лет.
Справедливости ради, именно для exec использование fork — весьма кривой оверкилл (если мне надо дёрнуть внешнюю тулзу из своей мегапроги, зачем для этого делать битовую копию памяти моего процесса? чтобы что?). Так что это скорее в unix-е не осилили нормальный CreateProcess.
Я правильно понимаю что вы не знаете о brk() и не в курсе ~40-летних рекомендаций по поводу его использования перед fork() + exec() ?
Тот же CoW был придуман еще до линуксов, ну и про posix_spawn() уже отметились.
Вот и имеем потом кучу раздутого говнокода от того, что они не понимают, как их библиотеки и фреймворки работают. Не говоря уже о том, что выдерни тот же POSIX — сломаются их библиотеки и фреймворки.
К сожалению, выпилят рано или поздно, как выпилили подсистему OS/2 из более ранних версий.
А кому-то сейчас нужна подсистема полуоси?
Наверное, никому (но это не точно). Фраза "к сожалению" относится не к OS/2, к WSL1. Если минусуют в поддержку выпиливания, то хотелось бы развернутого объяснения, почему это хорошо.
Не, я не за выпиливание. Как оно в итоге получится, в будущем увидим. Так то wsl интересная тема
Я даже HPFS на NT4 запускал. Работала в разы быстрее, чем NTFS. Хнык (
Была-была такая подсистема
https://www.itprotoday.com/strategy/nt-gatekeeper-disable-nt-servers-os2-subsystem
Даже отдельными бинарниками
Конечно даже при таком раскладе есть wine, но его можно опустить (все-таки это лишние телодвижения).
У меня есть макбук, у меня есть возможность установить линукс, но есть одна проблема — рендер шрифтов. Я так и не смог добиться качественного рендера шрифтов от мака (как и от линукса — где еще и периодически проблема с поддержкой моих двух мониторов и принтеров). Я даже жену подзывал, не объясняя, в чем суть, спросить — какой рендер лучше. И она сказала однозначно тот, который был на винде. Почему-то если смотреть на экран моего макбука, то там со шрифтами нет проблем. Но стоит мне его подключить к своему Dell U2415, так аж глаза болят через минут 15. Гугление ни к чему не привело (ну, кроме того, что, мол, отключите сглаживание — но именно оно мне в винде прям очень нравится).
у меня просто была аналогичная проблема, мне нравился линукс, но не глаза болели от шрифтов на FHD 24'' мониторе. теперь у меня ноут — 4k дисплей, монитор — 27'' 4k и я забыл что такое проблемы со шрифтами)
у вас на мбп нет проблем из-за высокой плотности пикселей. возьмите 4k дисплей и забудете о шрифтах вообще :)
Но я только что купил два эти монитора. Мне нравится их редкое соотношение сторон 16:10, нравится размер (больше уже смысла нет, а один монитор мне неудобно). И как бы странно покупать монитор под ось. Почему винда может рендерить достойно, а другие — нет? И потом, у линукса нет-нет, да бывают проблемы с двумя мониторами.
Как по мне, то линуксовый рендеринг с сглаживанием гораздо симпатичнее, но у лично у меня уставали глаза без донастройки, а у кучи других людей нет таких проблем. Виндовый рендеринг тоже ломает глаза, так как пытается своими алгоритмами встроить шрифт в пискельную сетку и создавая лесенку. С другой стороны я раньше сидел за TN матрицей и мне было норм на полной яркости и убунтовских шрифтах, а теперь глаза сильно избирательны — подавай откалиброванный IPS и все такое.
В общем, безотносительно операционной системы, 4к панель — это рай для глаз, плотность пикселей как на современном смартфоне. Теперь я не могу ни на винде, ни на линуксе с 96 dpi :)
Во-первых, у меня компьютер не только для работы, но и для игр. Здесь Windows однозначно лучше (Linux, конечно, тоже позволяет запускать игры, но какой смысл мириться с 50% совместимостью, если можно взять 100%?).
Далее, лично мне показалось, что Linux потребляет больше оперативной памяти. При этом, при достижении потребления к 100% система просто намертво зависала, не позволяя даже закрыть программы, которые съели все ресурсы (например, попытка открыть большой лог во встроенном текстовом редакторе KDE мне повесила всю систему). В Windows я хотя бы всегда могу открыть диспетчер задач — он всегда работает с повышенным приоритетом — и прибить ненужные процессы, избежав полного ребута системы.
Третье. Софт. Под Windows есть практически весь необходимый для работы софт. Огромное количество GUI-клиентов на любой вкус и цвет (мне, например, не удалось найти вменяемый GUI-клиент для GIT под Linux — да, мне удобнее использовать GUI, а не консоль). Также на Windows лучше работают программы самой Microsoft (кто-бы сомневался). Тот самый MS Office. Найти полноценную замену для Outlook для работы с Exchange Server опять же не получилось.
Уверен, можно возразить и найти множество вариантов «а вот это можно сделать так, а вот тут можно погуглить и сделать в итоге так». Однако главный вопрос — зачем? Что конкретно такого даёт Linux, чего не даёт Windows? Возможность запуска сервера? Так мне это не нужно — все серверы запускаются на машинах компании, на которую я работаю. Возможность сконфигурировать всё и вся? Зачем, если и так всё неплохо настроено?
Если что, я не хочу сказать, что Linux плохая система. Я лишь отвечаю на вопрос «зачем кто-то вообще пользуется Windows?»
сомневался). Тот самый MS Office. Найти полноценную замену для Outlook для работы с Exchange Server опять же не получилось.
До меня это было критично, хотя коллеги умудрились пользоваться OWA клиентом в браузере, поэтому я перешёл на MacOS и не жалею ни разу
О, а я как-то работал в конторе, где на мак перейти нельзя было, потому что безопасники только винду предпочитали. Основная проблема была в отсутствии клиентского сертификата, который выдавался на винду, но на мак, увы, нет. Из-за чего нельзя было залогиниться в сервисы MS. На винде он был при этом неэкспортируемым. И прав на его экспорт не было. Я, правда, извернулся, через какую-то незакрытую брешь вытащил таки сертификат, и запустил всё, что мне нужно было на маке, но если бы безопасники узнали...
У Linux и Windows разные подходы к организации памяти:
В Linux используется оверкоммит: приложение может выделить больше памяти, чем реально есть в системе, из-за чего out-of-memory может случиться в самые неожиданные моменты. В Windows оверкоммита нет, и в итоге возможна ситуация обратная: приложение при попытке выделить память получает отлуп, несмотря на то, что незанятой физической памяти дохрена и больше.
Windows превентивно скидывает в своп данные, даже если свободной памяти полно. Linux же это начинает это судорожно делать, когда память исчерпана. Впрочем, на ноутбуке, где по умолчанию используется встроенное видеоядро, при исчерпании памяти Windows тоже начинает чудить: временно отваливается графический драйвер, пока свободной памяти снова не станет достаточно.
Увы, у обеих систем управление памятью далеко от идеала.
мне, например, не удалось найти вменяемый GUI-клиент для GIT под Linux — да, мне удобнее использовать GUI, а не консоль
SourceTree, Sublime Merge
Windows превентивно скидывает в своп данные, даже если свободной памяти полно. Linux же это начинает это судорожно делать, когда память исчерпана.Это неверно. Почитай Руссиновича.
Виндовс просто часть .exe назначает свопом, и подгружает по необходимости. Потому у Вин своп технически есть всегда, а если Линух лезет в своп — это крит.проблема.
Виндовс просто часть .exe назначает свопом, и подгружает по необходимости.
Только это сказал не Руссинович, а Рихтер. «Windows для профессионалов. Создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows». Часть III «Управление памятью», глава 13 «Архитектура памяти в Windows»,
Виндовс просто часть .exe назначает свопом, и подгружает по необходимости.
Разумеется, линукс тоже умеет выгружать неиспользуемые куски открытых на исполнение бинарников.
Возможно, эффект от этого менее заметен, поскольку все нормальные дистрибутивы стараются каждую либу держать в единственном экземпляре, а в винде многие программы тянут свои версии популярных dll и суммарно это занимает больше места в памяти.
Это новая и, мягко скажу, вызывающая споры технология. Мне пока удаётся избежать счастья её использовать.
Let's Encrypt, по-всей видимости, на линуксе скоро будет только через snap.
Клиентская часть же всегда была пачкой скриптов. Некоторые их даже переписывали по разным соображениям. Зачем там snap?
Я имел в виду Certbot. Посмотрите инструкции к установке на разных осях. И вот, что пишут. У меня нет точной ссылки, где опубликовано решение о переходе на snap, но это решение, как я понимаю, принято.
есть и сторонние клиенты
Это как-то меняет тот факт, что Certbot переходит на snap?
Просто вы сказали, что
на линуксе скоро будет только через snap.
А сразу следующим комментарием я уточнил: "я имел в виду Certbot." Круг замкнулся :)
Еще раз: думал я о Certbot'е, но некорректно написал Let's Encrypt. Иных клиентов может быть сколько угодно, но в рамках разговора о snap, я хотел подчеркнуть, что есть популярные проекты, которые, по всей видимости, полностью планируют перейти на snap на линуксе.
https://packages.debian.org/search?keywords=certbot
елси даже LE сделает snap основным способом распространения certbot, исходники они не закроют, не думаю, что дистрибутивы перестанут опакечивать «по-своему».
Я бы в этот список добавил еще и докер. По сути для каждой софтины своё окружение.
Виндовс просто часть .exe назначает свопом, и подгружает по необходимости
Так делают все ОС, основанные на Mach VM, то есть примерно все после 80-х.
В Linux используется оверкоммит: приложение может выделить больше памяти, чем реально есть в системе, из-за чего out-of-memory может случиться в самые неожиданные моменты. В Windows оверкоммита нет, и в итоге возможна ситуация обратная: приложение при попытке выделить память получает отлуп, несмотря на то, что незанятой физической памяти дохрена и больше.
его можно отключить, но лучше не отключать, т.к. это сломает половину приложений...
продолжайте наблюдение )
Еще раз — логика очень простая — своп в линуксе есть — приложения коммитятся на его использование и на то, что оперативки можно хоть жопой жевать — следовательно при отключении мы ловим веселые эффекты. Эти эффекты МОЖНО побеждать с переменным успехом.
Хорошо! Хотите банальный пример. Мы написали некое приложение. Оно провело свою инициализацию, потом пошло в рабочий режим. Те странички памяти, которые были изменены в ходе загрузки приложения — грязные, поэтому не могут быть полностью discard, чтобы быть подтянуты с диска, но с другой стороны — они в процессе работы приложения могут не использоваться. Что с ними делать? Налицо неэффективное использование ограниченного количества ОЗУ.
С другой стороны, все мы понимаем проблемы, возникающие от наличия swap'а
Странная логика. Что мешает то же самое делать и под виндой?
В смысле? Не совсем понимаю.
Приложение обычно не интересует, сколько там в системе памяти и свопа.
Ему нужна память — оно памяти выделяет столько, сколько ему нужно вне зависимости от ОС. А если памяти не хватает, то отваливается по OOM.
Нет ) это не так работает.
В Линукс — приложение запрашивает память. И Линукс приложению память даёт. Если вдруг в процессе работы выясняется, что памяти не хватило — привет, оомкиллер.
В винде же — если памяти нет — приложение упадёт именно в момент аллокации несуществующей памяти. По крайней мере, это работало именно так. И соответственно, если приложение работает, то оно работает ) без приключений
Windows превентивно скидывает в своп данные, даже если свободной памяти полно
Линукс может так не делает, зато он любитель скинуть все в своп, когда активно используется дисковый кэш.
Windows превентивно скидывает в своп данные, даже если свободной памяти полно. Linux же это начинает это судорожно делать, когда память исчерпана.
В результате при тормозах Linux можно докинуть ОЗУ, а Windows тормозит всегда, но зато критическую ситуацию обрабатывает лучше. По моему опыту это сказывается на сборке больших проектов в фоне — на Windows становится невозможно пользоваться бразузером, потому что он постоянно своппится (хотя у него ещё много гигабайт свободной памяти), в то время как на Linux факт сборки проекта влияет только на температуру процессора (разумеется, это на хорошем железе, с большим количеством ОЗУ, SSD и т. д., на плохом железе страдания будут на любой ОС, просто с разным ароматами). И это на одном и том же железе. При этом у Linux есть хотя бы крутилка vm.swappiness, хоть и не идеальная, если не устраивает ситуация, а у Windows изменить поведение никак нельзя (совсем отключать своп тоже не лучшее решение, к тому же не отключается он полностью). При этом даже апргейд ПК не решит проблему, так как памяти изначально хватает. Разве что более быстрый SSD, чтобы Windows быстрее своппился, но SSD до RAM по скорости до сих пор далеко…
У меня делается бекап по расписанию. Дисковый кэш выталкивает в своп все приложения на серваке.
Что-то не так у вас с этим ночным бэкапом.
Чуть менее чем весь приличный софт для бэкапа читает (и тем более пишет) данные не загрязняя pagecache: используется O_DIRECT и/или O_DSYNC для open(), posix_fadvise(POSIX_FADV_DONTNEED) перед close() и т.п.
Если с упомянутым выше какие-то проблемы, либо используются какие-то собственные скрипты, то достаточно на время бэкапа подкручивать настройки /proc/sys/vm. Лучше посредством sysctl, например так:
- vm.vfs_cache_pressure = 222
- vm.dirty_background_ratio = 3
- vm.dirty_ratio = 7
- vm.dirty_writeback_centisecs = 1
- vm.dirty_expire_centisecs = 10
- vm.pagecache = 1
- vm.swappiness = 0
Соответственно, после завершения бэкапа вернуть исходные параметры (значение которых возможно тоже стоит продумать). Описание параметров легко гуглиться, вплоть до статей на Хабре.
Если проблема сохраниться, то я подумаю о том чтобы съесть свою шляпу.
Даже если это можно какими-то костылями и sysctl поправить, желания у меня особо нет это делать в любом случае. От свапа никакой пользы на серверах не вижу. Если не хватает памяти, то получаю честный OOM вместо тормозов, после чего иду и добавляю памяти виртуалке.
От свапа никакой пользы на серверах не вижу. Если не хватает памяти, то получаю честный OOM вместо тормозов, после чего иду и добавляю памяти виртуалке.
да все хуже на самом деле. Нет свопа — плохо, ОЗУ недоутилизирована (я выше писал почему). Есть своп — никаких гарантий того, что будет работать тоже нет. Более того — ООМ можно словить при штатной работе со свопом (!) даже при избытке свободной памяти. Короче, vm подсистема линукса — это реально кроличья нора
Это бэкап гитлаба. Он делается очень просто.
мы по-моему где-то обсуждали, что нужно декомпозировать гитлаб на отдельные сервисы (а не использовать омнибас) и снимать бекап другими способами ) например, на уровне LVM.
Это бэкап гитлаба. Он делается очень просто. В tar засовывает все репозитории и слепок базы и жмет gzip.
Это стандартная багофича большинства java-приложений с таким функционалом. Если не лень, то закиньте им багрепорт (целевой файл для tar нужно открывать с опцией O_DSYNC).
При этом, весьма вероятно, что у вас слишком большое значение vm.pagecache (процент памяти под кэширование) для ваших сценариев использования gitlab с учетом бэкапа. Поэтому за время бэкапа в кэш/память честно засасывается максимум читаемых tar-ом файлов, что выталкивает из памяти все холодные страницы.
SourceTree, Sublime Merge
Гит гуи обычно встроены в ваши ИДЕ: студия, IDEA,… И лично мне они куда удобнее оказываются чем сторонний тул. Хотя бы тем, что я прямо из мержа могу сделать go to definition, у меня адекватная подсветка, и т.п.
Со звуком проблем как-то не замечал (а с профессиональным аудио дела ещё лучше). Да и по описанию, это точно не проигрыватель конкретный тупил? За человеческие шрифты не скажу, но хинтинг поддерживается практически повсюду (Qt и GTK, а на них большая часть гуёв).
По шрифтам — у меня многие коллеги кодят под линуксом, ну и во время демонстраций экрана я вижу, что у них там происходит со шрифтами. Простите, но это кровь из глаз. Прыгающие кривые буквы, рандомный letter-spacing…
Со звуком выглядит интересно. В своё время тема в линуксе была больная, но относительно давно уже приколов с ним не встречал. Быстрый взгляд подсказывает, что pulseaudio крутится с сильно повышенным приоритетом (nice -11) — возможно, этим решили периодические разрывы.
Со шрифтами — спорить не буду. Только поинтересуюсь, в каких именно приложениях проблемы с ними. В этом плане есть ещё подарок в виде развлечения с настройкой всего интерфейса, включая шрифты и их рендер, что не принадлежит текущему рабочему столу, т.е. GTK приложений в KDE и Qt приложений практически во всём остальном. Это, увы, пока никуда не делось.
А шрифты человеческие завезли?
Да давно уже. А с 4K монитором рендеринг одинаковых шрифтов вообще неотличим.
Правда, виндовые шрифты утащить все равно пришлось, иначе документы MS Office открываются в высшей степени коряво.
звук-то починили, или до сих пор заикается, как во времена первых пентиумов, чуть только дёрнется диск чуть больше среднего?Возможно Вы про звук при полной загрузке CPU фоновыми задачами? Меня до сих пор это удивляет, почему «десктопная» ОС лучше справляется с работой с фоновыми приложениями. Строго говоря при максимальной загрузке это не очень частое явление, и чаще подмораживается не столько звук сколько GUI. Но это мне напомнило первое восхищение linux: mplayer — когда перемотка занимает не то что меньше 500мс, а меньше 50. Мелочь — а приятно, а при виде обратного впечатления не лучшие.
1) Тестовый файл Samsung SUHD_Phantom_Flex.ts (Тестовое 4к видео от Samsung), HEVC.
MPC-HC: в обоих случаях перематывает не более 5 кадров в секунду с артефактами как будто идут потери данных. (При установке через k-lite standard я видел установленную галочку «перемотка по ключевым кадрам» и ничего не менял). 3/5
Windows Media Player: больше не проигрывает видео? Звук был, видео — нет. 0/5
PotPlayer: Tест первый не более 2-3-х кадров в секунду. Тест второй — более 5-10 кадров в секунду, точнее не засекал, по ощущением перематывает так быстро как я нажимаю на клавиши. 4+/5
GomPlayer: Tест первый 0.2-0.5 кадров в секунду, если быстро водить то вообще 0. Тест второй — 2-3 кадра в секунду. 3-/5
mplayer/mpv: перемотка как в MPC-HC или чуть быстрее, но с теми же артефактами 3/5
2) Перекодировал тестовое видео с х264 normal, уровнем квантования 15 (обычный фильм, высокий битрейт) и переделал тесты.
MPC-HC: артефакты пропали, скорость выросла до 5-10+ кадров в секунду. 5/5
PotPlayer: ничего не изменилось по сравнению с предыдущим видео. 4+/5
Windows Media Player: видео открыл, первый тест не воспроизводится, второй 1-2 кадра в секунду. 2/5
GomPlayer: удалил эту вирусню, ставить не буду, не учавствовал в тесте.
mplayer/mpv: артефакты пропали, скорость выросла до 5-10+ кадров в секунду. 5/5
Ну что я могу сказать. MPC-HC сейчас показал себя так же как mplayer, отлично! PotPlayer, не смотря на то что работает медленнее, смог проматывать HEVC видео без артефактов, вероятно за счет другого кодека и в результате промотка там приятнее пользователю, но таки медленее. В итоге так же быстро может только один из 4-х протестированных видеоплееров. А Вы говорите «любой». Суть не в том чтобы перематывал по ключевым кадрам, а в том чтобы делал это быстро. К тому же один из этих плееров еще и установил мне аваст. Так что вот еще один фатальный недостаток windows инфраструктуры: мусорное ПО, отсутствие адекватного пакетного менеджера (магазина приложений) и как следствие при установке не очевидно что будет установлено, и нет механизма надежного удаления.
нет механизма надежного удаления.
Он есть в линуксе? Единственный механизм надежного удаление это приложения из microsoft store, которые ставятся в песочницу.
Он есть в линуксе?А чего нет? Нет удаления данных приложения? Или Вы о чем-то другом?
А бинарники приложение может запросто натаскать и без рута. И добавить их в автозапуск через какой-нить bashrc, cron и еще наверняка миллион других вариантов.
Вам похоже кажется, что пакетный менеджер умнее, чем это в реальности. Нет, пакетный менеджер не знает ничего, что не лежит внутри deb/rpm пакета. Приложение, postinst\preinst скрипты могут насоздавать все что угодно и пакетный менеджер об этом узнать никак не сможет. Поэтому да, все держится на порядочности того, что писал пакет, чтобы при установке не ставилось ничего лишнего, а при удалении удалялось действительно все.
Насколько в реальности это может проявиться это уже второй вопрос. Есть несколько вариантов. Если это встроенные репозитории, то там вряд ли такое будет, потому что, банально, мейнтейнеры дистриба вроде сами все эти пакеты собирают из сорцов. Они и выпилят, если что. Но это тоже самое, что рассуждать о приложениях от microsoft и о том, что ставится из windows update. Да или даже о вполне доверенных разработчиках вроде гугла, адоба и прочих. Там тоже таких вещей не будет.
Второй вариант это как вы выше рассматривали. Ставим что-то стороннее. У винды поставляться такое будет с сайта разработчика скорее всего. У линукса это будет сторонний репозиторий разработчика. Т.е. примерно одно и тоже в плане риска. В обоих случаях выпиливать приложение из интернета будет некому, если подсунуть что-то хочет сам разработчик приложения.
Поэтому единственными преимуществами пакетного менеджера в линуксах всегда была централизованная система доставки обновлений и, отчасти, управление зависимостями. Во всем остальном теже яйца только сбоку. Реальный скачок вперед это, как я уже говорил, песочница по типу windows store и apple app store. Вот там у приложений чисто физически нет возможности что-то не туда поставить или оставить после себя мусор. Но это правда несет с собой много новых проблем. В большинстве для разработчиков самих приложений.
Изначально речь была о «механизме надежного удаления»Ок. Я изначально не слишком формально выразился, признаю. Давайте так: «достаточно надежного механизма удаления, достаточно в той мере на сколько это возможно реализовать, но не более чем если бы это мешало удобству использования» Если позвать юристов то они еще на пару страниц расширят каждое предложение, чтобы не было никаких возможностей двойной трактовки, с чем мы сейчас собственно и имеем дело.
Продолжая по существу: с практической стороны «сторонних» в linux дистрибутиве существенно меньше, прямо единицы, по сравнению с windows.
Поэтому единственными преимуществами пакетного менеджера в линуксах всегда была централизованная система доставки обновлений и, отчасти, управление зависимостями.Лично для меня нет, и я выбираю дистрибутив именно исходя из широкой поддержки софта в стандартном репозитории потому что почти ничего не устанавливаю из сторонних. Я не добавлю какой-то Пупкин-рра себе чтобы поставить tcpping. Добавить же google-ppa для установки, скажем android studio — другой вопрос. А в windows я был бы вынужден и то и то качать из интернета. Android Studio из такого же источника, а мелкие утилиты — увы, источники у них всегда сомнительны.
Реальный скачок вперед это, как я уже говорил, песочница по типу windows store и apple app store. Вот там у приложений чисто физически нет возможности что-то не туда поставить или оставить после себя мусор.Т.е. из этих сторов нельзя установить браузер? Который может что-то скачать в систему?
Кажется аналогом является snap песочница. Которая не работает правда, потому что все ее избегают.
Кажется аналогом является snap песочница. Которая не работает правда, потому что все ее избегают.
Да.
Лично для меня нет, и я выбираю дистрибутив именно исходя из широкой поддержки софта в стандартном репозитории потому что почти ничего не устанавливаю из сторонних.
Значит, либо убунту, либо арч?
Сам я за opensuse, но не навязываю )
А в windows я был бы вынужден и то и то качать из интернета.
> scoop search android-studio
'extras' bucket:
android-studio (4.0.1.0)Эм… произвольно взятое приложение отсутствует в официальных репах линукса и обычно тащится с ppa или сайта разработчики. Или другой типичный пример — приложение в оф репе Дебиан/центос/убунту есть, но сильно устаревшей версии, а мейтейнерам пофиг. И приходится выкручиваться. И что там в стороннем репе — никаких гарантий, очевидно, нет. Так же как и при скачивании виндовых приложений не пойми откуда…
И что там в стороннем репе — никаких гарантий, очевидно, нет
ну если учесть, что «сторонние» репозитории — это обычно авторов софта, то доверия им не меньше, чем дистрибутивным.
Подписанный deb из ppa и скачаный по ftp/http (без s) бинарь — это риски одного порядка, так и запишем…
А вот не надо перевирать мои слова ) между прочим многие виндовые приложения внутри цифровую подпись имеют ) если, конечно, вообще разработчик этим озаботился. И вместо простого «мы вас записали в книжечку» лучше было бы подробно и развёрнуто свою позицию описать по данному вопросу
А никто не перевирает.
если, конечно, вообще разработчик этим озаботился
Вот именно.
Как вы себе представляете импорт ppa без подписи и импорта ключа?
Подписанный deb из ppa и скачаный по ftp/http (без s) бинарь — это риски одного порядка, так и запишем…
Подпись там ничего не значит, кроме того, что вы доверяет некому сайту из интернета, где размещен PPA.
Сомнительно, чтобы вы стали искать автора PPA и предъявить ему в судебном порядке за зловреда.
Она говорит о том, что это именно те файлы, которые были скомпилированы подписавшим пакет.
А не закладка от тащмаёра или Васи-кулхацкера, устроившего спуфинг у местечкового провайдера, а то и вообще подменившего точку доступа.
Она говорит о том, что это именно те файлы, которые были скомпилированы подписавшим пакет.
при условии, что он компилировал ) А не взял откуда то еще. Или еще может быть, что ключ украли (тоже такое бывало в истории).
А не закладка от тащмаёра или Васи-кулхацкера, устроившего спуфинг у местечкового провайдера, а то и вообще подменившего точку доступа.
с этим — да, сложно не согласиться.
А не закладка от тащмаёра или Васи-кулхацкера, устроившего спуфинг у местечкового провайдера, а то и вообще подменившего точку доступа.
Что мешает кулхацкеру Васе сгенерировать подпись?
Вы подписи проверяете на принадлежность не кому попало, а именно что доверенным людям?
Хоть раз в жизни проверяли?
Не то что подпись есть вообще. А что подписавшим можно доверять?
Представляете, время от времени да.
Кроме того, вы упускаете маленький, но интересный факт: просто сгенерировать свою цифровую подпись недостаточно. Пакетный менеджер просто откажется устанавливать пакет, и даже обращаться к подмененному репозиторию.
А что подписавшим можно доверять?
Вы хотите приравнять доверие к подписавшему к доверию к первому попавшемуся скрипт-кидди?
Демагогию чует каджит.
Представляете, время от времени да.
Как именно вы определяете что подписавший не кто попало?
Кроме того, вы упускаете маленький, но интересный факт: просто сгенерировать свою цифровую подпись недостаточно. Пакетный менеджер просто откажется устанавливать пакет, и даже обращаться к подмененному репозиторию.
Напоминаю вам:
Речь о PPA.
И сами эти репы и ключи с ними связанные изначально в системе отсутствуют.
То есть ключи для PPA ставите вы самостоятельно в явном виде.
Как вы определяете, что этим ключам можно доверять?
Где гарантия что вы поставили верные ключи?
Вы изначально доверяете PPA?
А что подписавшим можно доверять?
Вы хотите приравнять доверие к подписавшему к доверию к первому попавшемуся скрипт-кидди?
Демагогию чует каджит.
Отнюдь.
Скрипт-кидди тоже умеет подписывать это несложно.
Как вы проверяете истинность того, что подписавший не злодей?
То есть ключи для PPA ставите вы самостоятельно в явном виде.
Именно!
Как вы определяете, что этим ключам можно доверять?
Вы знаете, не всех еще забанили в гугле. PPA однозначно матчится с аккаунтом на launchpad, так? А значит и с пользовательским аккаунтом. аккаунтом, имеющим свою историю, ишью и коммиты (не всегда), кроме того этот аккаунт довольно просто связать с другими аккаунтами в Сети, кроме того вокруг каждого пакета и мейнтейнера существует, знаете ли, информационное поле, отличное от информационного вакуума.
И у скрипт-кидди из всего этого будет только свеженький аккаунт.
Сдается, вы то ли хотите выразить что-то неочевидное, то ли просто попутали ppa со свалкой пакетов в даркнете.
И давно ли, например, лично вы с ходу различаете Microsoft Corp и Microsoft Corp.? Не говоря уже про более другие варианты.
В целом, мы уже далеко ушли в оффтоп, а сомнений в том, что автоматическая проверка подписей надежнее ее проверки глазами и лапками (а то и полного этой проверки отсутствия).
На чем этот предлагает и закончить.
UPD: Этот занимается. Благо что это нужно делать не на каждом файле, а все раз — дальше все делает автоматика.
Сдается, вы то ли хотите выразить что-то неочевидное, то ли просто попутали ppa со свалкой пакетов в даркнете.
все так — ppa — это помойка. И я полностью согласен с sumanai что никто не верифицирует подписи. Как это работает? Берем инструкцию, например, по установке докера с оф сайта — первый шаг — добавьте репо ХХХ и ключ YYY. Ну, и вариантов как у потребителя у меня не остается — кроме как довериться доке… А если сайт взломают? :-)
Надо просто понимать, что (здесь согласен с Вами) — есть разные вектора атаки и разные уровни защищенности.
все так — ppa — это помойка
Да чего уж там, все цифровые подписи — это помойка, в корпорации людей много, соизмеримой ущербу ответственности никто никогда не несет.
Сколько уже раз утекали вендорские ключи? Не так давно M$ не стала удалять истекший сертификат потому что он нужен для верификации древних драйверов и компонент.
Ну и, на закуску, dseo13b.
Ну, и вариантов как у потребителя у меня не остается — кроме как довериться доке…
Вам в принципе придется довериться. Всегда.
Разница — только в этом:
разные вектора атаки и разные уровни защищенности
А откуда внезапно появилось такое условие?
ну, видимо, это отсылка к моему другому сообщению в совсем другом треде, где я рассказываю про то, как все кому не лень перехватывают http/ftp (без s) трафик....
sumanai, gecube
И вы можете уже гарантировать, что никакой виндософт так не распространяется?
http://skse.silverlock.org/download/archive/ — с официальной страницы ссылка.
Проверить наличие цифровой подписи сходу возможным не представляется — гранаты не той системы.
Всякий софт со своими апдейтерами тоже всегда-всегда качает по https, использует свежую библиотеку ssl/tls, в браузере у конечного пользователя нет никаких подозрительных расширений?
У нас, в настоящем — нет.
Так эти же самые допущения допустимы и в отношении gpg!? Те же коллизии, слабые шифры, ошибки в кодовой базе и т п? И о чем тогда разговор?
Для этого вам сначала надо будет установить старые либы и софт, нет?
Или долго-долго-долго специально не обновляться, чтобы даже security протух.
Но даже в этом случае, как вы собираетесь осуществлять атаку коллизией, если все, что делает цель, это получает пакет, а сличение и аутентикация производятся локально? Это же не https, никакого клиент-серверного взаимодействия.
В любом случае, дискуссия скатывается уже к раз любой замок можно взломать — то замки ставить не нужно…
адекватного пакетного менеджера (магазина приложений)
Наличие пакетного менеджера ничего не гарантирует. Приложения, установленные через rpm / deb — точно так же оставляют после удаления конфиги и пользовательские Файлы. Плюс мы надеемся на грамотность разработчиков — что они правильно написали все манифесты, которые описывают где и какие файлы приложения располагаются… что далеко не всегда так
магазина приложений
Вот чего чего, так этого нет в линуксе, зато есть в винде (ms store).
«что они правильно написали все манифесты, которые описывают где и какие файлы приложения располагаются…»
Вот мне казалось (со стороны пользователя) что если файл установлен пакетным менеджером то он будет обязательно зарегистрирован в системе (всегда можно узнать какой файл принадлежит какому пакету и список всех файлов пакета) и будет так же удален во время удаления. Неужели это не так? А то что конфиги остаются… ну да… Но не бинарники в автозагрузке.
Конфиги и пользовательские файлы и должны оставаться. Представьте, что удаляете MS Office, а он все .doc-файлы с машины сотрёт?
я бы предпочел сценарий, когда мне предлагают выбор в явном виде )
И обязательно — нормальная документация — что и где лежит и почему так, а не иначе.
С теми же конфигами — никогда не сталкивались, что новая версия ПО ХХХ, глючит или не работает с конфигами от предыдущей?
В тех случаях, когда расположение конфигов и файлов отличается от стандартных юниксовых конвенций (их и так все знают), о них и так в доке пишут. А хороший софт пишет об этом в man-странице и вообще всегда, в секции FILES.
И если вдруг случается редкий случай багов со старыми конфигами, всегда достаточно старые переименовать (а не удалить — мы же делаем бэкапы, правда?), чем для каждого случая сноса пакета расспрашивать меня про конфиги каждого юзера на машине, или, того хуже, удалять их без спросу. Ведь это удаление пакета могло быть временным, например.
Тащем-та вся суть философии Unix заключается в том, что машина — раб, и делает то, что ей сказали, поэтому нечего ей трогать мои конфиги (ведь это я их создал, а не пакетный менеджер), пока я явно этого не захотел. Контроль в руках администратора.
Пост поражает своей некомпетентностью
Местами статья выглядит как ода технологиями Windows, большинство из которых никогда не тянули на пафос "подвиг архитектурной мысли и реальной программной разработки" (посмешило, конечно).
Посему ниже несколько колких уточнений.
Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле.
Не в каком-то, а в прямом смысле — провал относительно исходных целей.
Причем специалистам это было более-менее понятно сразу (NTFS проще выкинуть чем ускорить, а некоторые вещи невозможно совместить принципиально). WSL1 не может (и не сможет) обеспечить весь функционал Linux из-за фундаментальных ограничений ядра NT. Какие-то вещи (например clone/fork) были реализованы, но многое не возможно (уменьшение mmap-секций, блокировка файлов и т.д.).
сначала взглянем на WSL 1, и первым делом — на её странное название. Почему эта функция называется подсистемой Windows… для Linux?
Потому-что такова конечная цель (WSL3). Тут стоит отметить что поверх ядра Linux точно возможно реализовать NT API (aka Native API), обеспечить работу подсистемы Win32, работу USB и NDIS-драйверов, и даже части других нативных драйверов. Но неизбежно "отвалятся" драйверы дисков, все завязанное на внутренний кошмар NTFS и внутренности win32.sys, с массой неизбежных регрессов из-за нарушения совместимости (в том числе и ожидаемыми Windows-багами). Поэтому интеграция на уровне виртуализации (WSL2) выглядит разумным переходным решением.
Windows NT разработана с нуля для поддержки процессов, запущенных из множества операционных систем, а Win32 был «просто» одной из этих подсистем окружения.
Это было ~30 лет назад в эпоху Windows NT 3.51. Начиная с Windows NT 4.0 подсистема Win32 потекла в ядро, а начиная с Windows 2000 ядро NT стало уродливым мутантом — уже менее гибким, потенциально уязвимым и небезопасным, но еще не быстрым. Буквально к исходной NT-архитектуре (далеко не идеальной, но более-менее строгой) Win32-говно прибили палками.
Стоит отметить, что 20-30 лет назад модульность ядра NT (деление на подсистемы со стабильными API, стабильный API для драйверов, идеи IRP-стека для интеграции драйверов и даже NDIS) выглядели очень здравыми и перспективными. Но на деле всё это постепенно стало профанацией и маркетинговым трепом. Де-факто воплощение идей обернулось кошмаром:
- подсистемы не изолированы, а сплетены в клубок, взаимосвязанность зашкаливает, их невозможно развивать, заменять и/или использовать по-отдельности.
- актуальная стабильность ядерных API и ABI не гарантирует совместимости между версиями даже на уровне исходного кода драйверов.
- комбинаторная сложность не позволяет проверять релизы (корень эпических сбоев после обновлений) из-за огромного зоопарка версий драйверов у пользователей, исходный код которых вне какого-либо централизованного контроля и code review.
Тут напрашивается премия Дарвина, а не эпитеты типа "подвиг архитектурной мысли и реальной программной разработки" ;)
были реализованы, но многое не возможно (уменьшение mmap-секций, блокировка файлов и т.д.).
А пруфы для этого есть где-то? Ни та, ни другая ссылка ничего подобного не говорит. Вторая, судя по всему, фиксится тривиально.
А так, кулстори.
Если знать тему (подробности соответствующих системных вызовов в POSIX и ограничения ядра Windows), либо хорошо вникнуть, то это будет очевидно как 2+2. Иначе говоря, "пруфы" сводятся к поиску и сопоставлению фрагментов соответствующих RTFM. Но готовых ссылок на подобные пояснения у меня нет.
Если совсем кратко, то в спецификации NT и Win32 API, по принципу "назло бабушке уши отморожу", намерено закладывалось максимум отличий от POSIX. Некоторые отличия таковы, что их невозможно совместить при работе с одним объектом (файлом).
Даже если (вдруг, невзирая на риск регрессов, на сложность и объем доработок) M$ реализует в ядре обе семантики/спецификации, то файл открытый в Win32 уже нельзя будет открыть в xWSL, и наоборот. А вишенкой на торте будет производительность — т.е. файловые операции Linux будут работать с черепашьей скоростью NTFS и т.д.
Если многократно натягивать технологии на бизнес, то либо бизнес сожмется, либо технологии лопнут — M$ с Windows демонстрирует оба варианта.
А безумство+отвага с clone/fork в M$ будут помнить еще долго, от того и "планы у бизнеса поменялись" ;)
Как говорится нормальные герои всегда идут в обход ;)
Полчаса потратил, но нашел коммент, который как мне кажется неплохо приводит пачку примеров несовместимостей: https://habr.com/ru/company/selectel/blog/521714/#comment_22138182
Не знаю что там работает, я на одной из последних версий тупо гццшкой не смог скомпилировать проект, падал где-то в кишках. Разбирался-разбирался, плюнул, поставил убунту в виртуалку, ровно тот же самый коммит тем же гцц компилился без проблем.
Поэтому немного жаль идеологическую чистоту, но надежность наверное важнее
Проблема в том, что чтобы любая программа для Linux чувствовала себя под таким эмулятором «как дома», недостаточно реализовать все системные вызовы Linux (а их там совсем немного, и они в основном достаточно простые). Надо еще реализовать очень многие детали поведения устройств, сетевых протоколов и т.д. и т.п. К примеру, ifconfig в Linux делает свою работу, путем передачи ядру «команд» в виде «сообщений» через специальный сокет, и обработки ответов от ядра, которые тоже приходят в виде таких сообщений. Чтобы ifconfig работал в WSL 1, WSL 1 должен понимать содержимое этих сообщений, да еще и переводить их между той концептуальной моделью сетевого стека, которая реализована в Linux, и той, которая реализована в Windows, а они разные.
Сделать все это аккуратно и с достаточным уровнем точности — это титанический труд.
Проще, мне кажется, запустить нормальное ядро Linux'а в виртуальной машине (как сделано в WSL 2), и по мере необходимости отдельно добавить каналы взаимодействия, через которые системы могли бы обмениваться конфигурационной информацией (например, сделать сетевой интерфейс Linux в виде скрытого бриджа, разделяющего доступ к физическому интерфейсу с Windows, и при изменении параметров сети на стороне одной из систем автоматически прокидывать эти изменения в другую систему).
При этом нет необходимости эмулировать все, достаточно поддержать только то, что нужно.
Как здорово использовать ifconfig (аналог ipconfig из Windows, хотя есть ещё ip) в рамках сеанса WSL для проверки и изменения сетевых интерфейсов компьютера?
А нужно ли кому-то это? Это наверно вопрос к Системным администраторам.
На моей практике я ни разу не видел использование ни SFU (Windows Services for Unix) ни WSL1/2 в рабочем окружении.
Один мой коллега использует WSL2 для работы с Azure, но тогда можно использовать и PowerShell или AzureCLI.
На удивление, wsl --set-version конвертация 1 -> 2 и наоборот работает идеально. А вот wsl.exe --export и wsl.exe --import — нет. Во-первых, они могут съесть все 32гб оперативки, во-вторых, некоторые образы при импорте падают с Unspecified error. Как при импорте 1 версии, так и 2. Другие образы, только установленные, импортируются нормально и быстро.
Пробовал такой конфиг .wslconfig, но безрезультатно:
[wsl2]
memory=20GB
processors=8Если кто-то сталкивался и решили проблему, расскажите как удалось.
Posix acl не сильно то дальше ugo ушли, так что ждём реализации NFSv4 ACL, которые действительно совместимы с виндовыми, потому что калька.
Я вспотел но так и не понял логики, к чему там этот мозговой выверт?
The default behavior of setfacl is to recalculate the ACL mask entry, unless a mask entry was explicitly given. The mask entry is set to the union of all permissions of the owning group, and all named user and group entries. (These are exactly the entries affected by the mask entry).
если я вообще понял вопрос
$mkdir test
$ls -al ./test
drwxr-xr-x 2 user1 user1 4096 янв 7 12:16 test
$setfacl -m u:user2:rwx ./test
drwxrwxr-x+ 2 user1 user1 4096 янв 7 12:16 test
$getfacl test
# file: test/
# owner: user1
# group: user1
user::rwx
user:user2:rwx
group::r-x
mask::rwx
other::r-x
Пока все вполне предсказуемо
$chmod 644 test
$ls -al test
drw-r--r--+ 2 user1 user1 4096 янв 7 12:16 test
И тут внезапно, чего совсем не ждали.
$getfacl test
# file: test/
# owner: user1
# group: user1
user::rw-
user:user2:rwx #effective:r--
group::r-x #effective:r--
mask::r--
other::r--
chmod 646 test
getfacl test
# file: test/
# owner: user1
# group: user1
user::rw-
user:user2:rwx #effective:r--
group::r-x #effective:r--
mask::r--
other::rw-
Какая связь традиционных прав unix и уже выставленных acl? Почему изменение owner не влияет на acl а group влияет?
Я пытаюсь понять логику такой задумки.
потому что мы ничего не знаем про acl и хотим поменять ugo.
Но речь то за другое. Выставил пользователь файлу acl а система отчего то при операциях с им пользуется ugo.
Получается винегрет, это как-то не совсем то чего ожидаешь.
Ладно бы использование acl отменяло ugo, так нет же, работают обе и одна влияет на другую, но не наоборот.
Как по мне это несколько странно.
Я, в целом, в принципе не понимаю зачем это влияние ugo group на acl. Не owner и не other а именно group. Это же именно специально задумано так.
Они разные, но не надо говорить что есть только «ограничение в три цифры». Как минимум цифр четыре, плюс acl.
про дополнительные биты вроде setuid, sticky bit.
это должно быть легко реализуемо на NTFS — через те же File Streams, ну, и в конце-концов как-то же раньше слой совместимости с POSIX работал в винде… Даже если setuid и sticky bit не будет, то не такая большая потеря так-то.
Меня в этой связи больше волновало бы setcap штуки (которые через отдельные линукс атрибуты файла вроде как работают и вообще параллельная вселенная по отношению к acl)
sumanai
Странно всё это выглядит. Хочется Linux — загружаюсь в Linux. WSL не нужон.
ifconfig (аналог ipconfig из Windows
Серьезно? Аналог?
Представьте… любой из них можно убить командой kill
> kill %1
> приложение kill не отвечает…
Представьте, как здорово набрать ps или top в сеансе WSL и увидеть рядом процессы Linux и Windows, причём любой из них можно убить командой kill?
Вызвали kill, который должен доставить сигнал 9 приложению.
Что делать «винде» дальше?
Запускал из крона wsl-ной убунту программы в виндоусе (например, мои скрипты автотестирования Selenium). Работало, удобно. Но сама убунту кажется урезанной и куда ни ткнись какие-то ограничения и не доделки. Идея, помню, мне очень зашла, но реализация и правда так себе.
Сделают на виртуалке — да и славно. Лишь бы лучше работало.
Надеюсь, вы согласитесь, что главным преимущество Windows 10 — это её стабильность, хорошая стабильность при исполнении программ и какая-то, я бы сказал, предсказуемость. У линукс десктопов пока что есть подглючки.
Но в части юзабилити винда реально не the best. Им есть куда расти, не все можно настроить. И плюс сама настройка множества параметров идёт через реестр, а там названия технические, трудно ориентироваться.
В общем, кажется, что ещё немного и дистрибутивы линукс начнут вытеснять винду. Если посмотреть на возможности manjaro или mint, то они становятся крутыми визуальными системами, которые где-то даже удобнее винды. Остаётся только все программы перенести под них и вперёд, на линукс.
Раньше у Microsoft был ещё один супер продукт — офис. Но сегодня я предпочитаю googledoc, тк любые документы легко шарить и работать совместно (что дома, что на работе). Думаю, эпоха Microsoft плавно будет подходить к концу.
Интересно, сколько займёт это Microsoft-озамещение…
Утраченный потенциал подсистемы Windows для Linux (WSL)