Поломался WSL2 после вчерашнего вторника обновлений

Полное шифрование дисков и secure boot +

Какие с этим проблемы? Я так понимаю дистрибутив Arch/Gentoo?

Они уже 11 выкатили, на хабре был пост про попоболь виндоюзеров. И комментарий одного из них: «Если это „худшие особенности“, то система должна быть очень неплохая». Занавес.

В общем, там теперь две службы место одной, и вторая – уровня пользователя, запускается, когда я начинаю юзать WSL2 и останавливается – когда заканчиваю.

Я, конечно IIS почти не пользовался, но насколько помню там были нормальные сообщения в логах.

Это не совсем системный софт в винде (и да, тоже неудачный с т.з. сообщений об ошибках)

Может лучше сравним gcc и msvc?

Тоже не хочу, это специализированный софт, не системный.

А документация от Microsoft?.. Это просто шедевр. Убеждён, что он специально пишется так, чтобы по ней невозможно было понять ничего.

Документация у них нормальная, настолько насколько может быть нормальной документация описывающее не нормальное.

Пользователи API Microsoft должны работать в Microsoft. А там у них будет внутренняя документация и менторы.

Вы думаете как-то по другому можно описать этот кошмар? Ну разве что наплодить кучу примеров и загнать всё это в огромный faq из которой индусы будут копипастить.

Нету внутренней документации. Разработчики Microsoft пользуются https://docs.microsoft.com/

По недокументированным функциям документацию пролюбили?

Документация у них нормальная, настолько насколько может быть нормальной документация описывающее не нормальное.

Я привык, что по тем технологиям, с которыми работаю (OpenSource) документация делится на три категории:

1. Туториал, где объясняются основы на пальцах, с подробными примерами. Не всеобъемлющий, но позволяет «войти» в технологию, начать понимать её основы.
2. Собс-но основная документация, где по разделам описываются возможности технологии, и как их использовать (с примерами).
3. Reference. Сухое сжатое перечисление всего, что входит в технологию (например, для ЯП — грамматика с очень кратким пояснением каждой конструкции).

Прошу прощения за вольные определения, пишу на бегу.

В Microsoft, по крайней мере, в той области, с которой имею дело я (не могу сказать из-за NDA, какой именно), есть только один(!) третий тип документации. А именно, спецификации, reference.

Нет ни туториалов, ни примеров, ни другого вида документации. Есть только десятки документов, читая которые ты узнаёшь определения, но нет возможности сложить их в общую картину, и совершенно нет понимания, как они стыкуются вместе.

Например, сможете ли вы настроить сервер nginx, если у вас есть только спецификация HTTP? Сомневаюсь, и это ещё простая задача. У меня задачи сложнее…

Нету внутренней документации. Разработчики Microsoft пользуются https://docs.microsoft.com/

Шо и даже по «скрытым» функциям нэма?

Ubuntu. Да никаких проблем, за исключением того, что надо повозиться для настройки шифрования диска полностью включая /boot, не работает уход в сон и ядро только подписанное работает т.к. secureboot.

Ну я и написал, описание «не нормального».

Сначала перезагрузить

Бесполезная трата времени.

переустановить

Вот с этого и надо начинать.

Даже говорили про то, что никакой скрытой документации нет,

А есть глобальный индексер всего кода MS. Получше всякой скрытой документации будет.

Бесполезная трата времени.

а ты 3 раза пробовал? всегда делай это три раза!

Про бубен забыли.

Переключение между встройкой и дискреткой.

Давно не актуально. Сейчас даже зелёный блоб через prime работает

Шо и даже по «скрытым» функциям нэма?

emorozov

Вот я спросил у уважаемого Stephan T. Lavavej:

https://imgur.com/a/cgaYEiu

Спасибо, интересно.

Но я всё же не убеждён, по нескольим причинам.

1. Microsoft — огромная компания, один человек, какую бы должность в ней не занимал, не может знать всё. По своему опыту, уже в компании от 100-150 человек мне просто не хватает времени и возможностей, чтобы узнавать, что происходит в других отделах, какие там практики, и какая в них документация. У Microsoft очень много различных продуктов, в каждом продукте наверняка куча команд, в итоге, даже какой-нибудь монстр может удержать в голове возможно в несколько раз больше информации, чем я, но не всю.

2. Уверен, что каждый подписывает жёсткое NDA. По-другому западные компании не работают, даже в самой захолустной веб-дрисне попросят едва ли не до собеседования подписать NDA. И наверняка никто не может публично ответить на вопрос, не согласовав это сначала с внутренним, а затем и штатными цензорами.

3. У сотрудников Microsoft просто другой угол взгляда на проблему: он всегда может подойти к соседу за справкой, назначить митинг, отправить письмо в соотв. отдел. Скорее всего, после 20 лет работы он сходу сможет назвать любого человека, к которому внутри компании можно обратиться по поводу любого API. Ему в принципе уже невозможно понять проблемы человека, находящегося по другую сторону баррикад.

4. Дополнение к предыдущему: он всегда может посмотреть в исходники, в отличие от нас.

в отличие от нас.

Часть доступно.

Исходники стандартной библиотеки С(UCRT) и стандартной библиотеки С++ доступны.

Из них видно, что, стандартная библиотека С в Microsoft написана на С++ :)

Исходники ядра, да, недоступны.

Могу ещё дополнить из своего опыта: в любой нормальной компании, особенно западных, когда ты начинаешь работать в какой-то новой области, тебя никогда(!) не отправят читать доки. Даже если они есть, неважно, публичные или внутренние.

Первое, что сделают в западной компании (и у нас тоже во многих компаниях) — скажут: «Вася, у нас есть сотрудник Петя, который на этом API/этой библиотеке собаку съел. Договорись с ним о времени встречи, он расскажет тебе, как начать работать с этой штукой, это продуктивнее, чем отправлять тебя читать доки».

И опять же, человеку, находящемуся по эту сторону баррикад, не к кому обратиться, если мы начинаем пользоваться каким-то новым API от Microsoft. Мы не можем обратиться к людям, которые это API сделали. Мы не можем даже сказать им, что их доки - говно.

Дык, я нигде не говорил, что у меня проблема со стандартной библиотекой C++!

Я работаю над совсем другими API. На стандартной библиотеке далеко не уедешь, если нужно что-то сложнее Hello, world.

Мы не можем обратиться к людям, которые это API сделали. Мы не можем даже сказать им, что их доки - говно.

Вот сюда я комитил несколько своих изменений: https://github.com/MicrosoftDocs

В частности в https://github.com/MicrosoftDocs/cpp-docs

Там и люди есть, и их email или другие контакты, если хочется им что-то сказать :)

Вы верите что компания которая клепала не документированные функции в дос, внезапно перестала это делать в последующих продуктах? Я вот как-то не очень.

Ей-богу, я был уверен, что в 2021 году никто не пользуется убогим SOAP, думал, что это убожество похоронили ещё лет 15 назад.

1.2 ещё 15-ти лет не исполнилось

Unknown error at unknown location 0x10002dce

Ну Segmentation fault как бэ не намного информативнее.

Ну Segmentation fault как бэ не намного информативнее.

Он умолчал, но главная проблема это заставить приложение отдать тебе код ошибки. Иногда винда просто ваншотает приложение без вызова UEF и без вывода своего окна о том, что приложение было завершено с краткой инфой о причине.

Могу ошибаться, но вроде Unknown error at unknown location это теже в профиль Segmentation fault при работе «не по адресу». Тоесть без проверок приложухе нечего отдавать, а была бы проверка так и приложуха не упала бы.

1.2 ещё 15-ти лет не исполнилось

И что? Никто в мире SOAP не пользуется, т.к. это мертворожденный стандарт, неудобный и неэффективный. Он просто вымер везде, кроме Microsoft.

Когда в любой компании выбирают протокол взаимодействия частей системы, SOAP никому даже в голову не приходит называть. Это всё равно что при выборе способа доехать от Москвы до СПб — поезд, самолёт, автомобиль — ляпнуть: «На телеге, запряженой ослом». Все посмеются, и скажут: «Молодец, пошутил».

А Microsoft использует SOAP, в т.ч. в относительно новых API и продуктах.

Ну Segmentation fault как бэ не намного информативнее.

Я сейчас говорю об ошибках, которые возвращают вызовы API Microsoft. Там нет понятия «сообщение об ошибке». В большинстве случаев, они возвращают только код. Иногда к этому коду приписывается пара слов. Часто одно из этой пары слов — «unknown».

Логов нет. Есть Event Viewer, в котором газиллион веток, многие из которых приходится по одной анализировать, чтобы найти, есть ли в ней что-то относящееся к проблеме. Часто нет.

А если и есть какой-то event, то в его описании в 99% случаев не сильно больше информации, чем было в коде ошибки. Часто там тот же код ошибки, те же два слова, ну и ещё таймстемп. Становится сильно понятнее, да.

И что? Никто в мире SOAP не пользуется, т.к. это мертворожденный стандарт, неудобный и неэффективный. Он просто вымер везде, кроме Microsoft.

Ога, не далее как лет пять назад припиливал передачу данных используя этот «мертворожденный» стандарт и таки до лета этого года оно так и работало. С учетом кому это предназначалось, посмею предположить что там усе так работает. Моя система это одна из многих-многих-многих и требования в виде soap это их требования были.

А сами бы вы выбрали SOAP? Для себя, если бы для своего проекта выбирали? Только честно.

Какие есть причины в пользу выбора SOAP?

Ведь таких причин нет. SOAP всегда был неудобным неуклюжим станадартом. Microsoft понятно почему использует: это махина с огромной инерцией, и работая в ней наверное заманаешься объяснять своему менеджеру, почему лучше взять что-то другое, а тому надо будет объяснить своему менеджеру и так вверх по гигантской цепочке. Поэтому они заложники своего положения, и я это понимаю. Что не делает мой опыт работы с Windows приятнее.

Вы верите что компания которая клепала не документированные функции в дос, внезапно перестала это делать в последующих продуктах? Я вот как-то не очень.

Я верю в то что документация для публичных функций находится в docs.microsoft.com

И в то, что другие отделы не пользуются деталями реализации сторонних команд. Так как другие люди могут всё поломать в вашем коде. Если какая-та функция нужна, то нужно договоравиться с теми, кто этот код делал, чтобы её сделали публичной.

Также я признаю, что бывают проблемы. Например в студии есть XAML diagnostics API. Но он не публичный. Так что разработчики сторонних плагинов для студии, либо должны не использовать эти возможности, либо реверсить как-то это API и адаптироваться под изменения. Но правильный путь, это убеждать запросами Microsoft сделать публичным какое-то API если оно вам нужно.

Открыть API это не так просто. Так как тогда Microsoft должна взять на себя обязательства не ломать это API долгие годы. Нужно пользоваться публичными API, тогда будет отличная переносимость программ и гораздо лучшая документация, чем полагаться на приватные функции, которые могут быть выпилены в следующем обновлении.

А сами бы вы выбрали SOAP? Для себя, если бы для своего проекта выбирали?

Если бы показалась, что оно подходит, то возможно да.

SOAP всегда был неудобным неуклюжим станадартом.

Встречные вопросы.
1. А что именно неуклюжего вы в нём увидели?
2. Какие альтернативы предлагаете?

Открыть API это не так просто.

Вы сейчас про публичное API или про внутреннее барохло м$ ?

Так как тогда Microsoft должна взять на себя обязательства не ломать это API долгие годы.

А она когда-то ломала в рамках версии?

Нужно пользоваться публичными API, тогда будет отличная переносимость программ

В рамках одной версии. Или N версий, если нам будет не лень накостылять кучи sizeof(typename)+-magic-constant, причем magic-constant бывает приходиться подбирать опытным путем.

Пример сообщения об ошибке Microsoft: https://answers.microsoft.com/en-us/xbox/forum/all/microsoft-store-failed-update/2ed42191-215c-4f09-b547-5e711857118a

Это не я столкнулся, и я не с этим работаю, просто наткнулся случайно.

“installation stopped error code 0X87af000d”

Оооооочень информативно. И у них всё так.

И очень типично, что ответ поддержки начинается с предложения перезагрузить.

Лично я когда гуглю свои ошибки, тоже очень часто натыкаюсь не на объяснение кода ошибки, не на шаги по исправлению, а только последовательность: «Перезагрузи, обнови, переустанови».

Или вот работаю с веб-сервисом Microsoft. На половину запросов получаю:

{"code":"InternalServiceFault","data":[],"details":[],"message":"Internal service fault.","source":"Orion.MTS"}

В доке написана вообще пурга, например, перечислены параметры, которых вообще нет.

Да, я даже нашёл эту доку на github. Как я создам Pull Request, если я не знаю, что на самом деле должно передаваться?

Да это просто капец какой-то… Куда не плюнь.

Язабан

+1