​​Неожиданные особенности встроенных видеокарт AMD

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

Хитом среди таких ПК являются устройства на новых процессорах Intel N100, который по вычислительной мощности соответствует Core i5 четвертого поколения, а купить подобный ПК в сборе можно, начиная от 15 000 руб.

В ценовой категории 33 – 35 тыс. руб. находится другой хит - Ryzen 5 6600H с поддержкой памяти DDR 5, это уже серьезная вычислительная машина с широкими возможностями, учитывая, что платформа поддерживает до 64 ГБ памяти.

Но в ходе эксплуатации открылись некоторые неожиданные особенности работы встроенного видео.

Если вы эксплуатируете подобную систему без подключенного монитора и подключаетесь к ней через программы удаленного доступа, такие как AnyDesk, Rustdesk, Aspia и т.п. то системы от Intel отдают картинку в разрешении FHD (1920x1080).

Системы на AMD в такой ситуации отдают экран в минимальном разрешении 640х480 и программно изменить такое поведение нельзя. А в таком разрешении не то, что сложно выполнять какие-то работы, а просто невозможно даже минимально использовать современные ОС, потому что в экран не помещается ровным счетом ничего.

Решений этой проблемы простое – покупка эмулятора монитора HDMI по цена 150 – 200 руб. Но этим вопросом стоит озаботиться заранее.

👉 А еще хотим передать горячий привет всем, кто планировал ударно поработать на майские, но праздники внесли свои суровые коррективы. И еще раз напомним – так делать не надо.

​​Нет пророка в своем отечестве

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

Если послушать таких ораторов, то все сводится к тому, что нашего у нас ничего нет и быть не может. А все что у нас возможно – это взять где-нибудь в Китае подешевле, перекрасить и продать у нас подороже.

С обязательными распилами и откатами… Ну как без них. А все попытки трезво разобраться в ситуации сразу же объявляются заказухой и чуть ли не соучастием в освоении бюджетных средств.

Начнем с коррупции. Она, как это не прискорбно, существует, но это не является какой-то отечественной особенностью. Коррупция – явление международное. Не так давно в Конгрессе США демонстрировался пакет с обычными гайками за $90 тыс.

И на вопрос: как же так вышло? Ответ был в стиле: ну как-то так получилось…

А мы пока пойдем дальше. Есть такой дистрибутив – Linux Mint, который представляет собой пакетную базу Ubuntu плюс собственная графическая оболочка Cinnamon. И никто не отказывает ему в звании отдельного дистрибутива.

А теперь берем Astra Linux, который не просто использует пакетную базу Debian, но и пересобирает и сертифицирует ее. И также предоставляет собственную графическую оболочку Fly, это не считая остальных корпоративных разработок, таких как мандатная система доступа или ALD Pro.

И тут же начинается: фу… взяли Debian и продают, а Fly вообще-то на базе KDE…

И что? В Mint взяли Ubuntu, а Cinnamon вообще-то на базе GNOME…

Продают? Так никто не запрещает. А чужие деньги считать, как минимум некрасиво.

А еще есть Альт, который вообще сейчас полностью самодостаточный и самобытный. Но нет, тоже не так. Оказывается, там под капотом зарубежное ядро Linux и прикладной софт тоже не сами написали.

Но тогда, товарищи, надо быть последовательными. И если Альт жалкое заимствование, то к нему в компанию надо отправить и SUSE, и Ubuntu, и всех остальных, оставив разве что базовые дистрибутивы.

Хотя, а их за что? Тоже взяли чужое ядро и чужой софт. Вот нефиг, пусть сами пишут.

Ну ладно, погорячились. Но ведь они берут бесплатно и продают за деньги? А вот здесь сходите и расскажите это компании IBM и ныне подконтрольной им Red Hat.

Они делают ровно тоже самое, так еще и вставляют палки в колеса попыткам распространять их творчество бесплатно. Историю с CentOS знают все.

Что касается железа, то сегодня не столь много мест, где можно производить высокотехнологичное оборудование. Та же продукция Apple производится в Китае, что не мешает ей нести гордую надпись «Designed by Apple in California».

Сегодня собрать железку много ума не надо, только вот ее кто-то должен до этого разработать.

Поэтому нет ничего страшного, что наши разработки производятся Китаем. Это не отменяет того, что они наши.

А вообще с Китая надо брать пример. Там никто не комплексовал по поводу «взяли чужое и перекрасили», причем сделали это крайне похабно и паршиво. Первые китайские поделия хоть в электронике, хоть в автомобилестроении вызывали только слезы.

Зато на них набили руку как в производстве, так и в разработке. Сегодня половина мира ходит с китайскими телефонами и ничуть не комплексует. А некоторые бренды создали устойчивые фанатские сообщества, как тот же Xiaomi.

Следом на рынок идут китайские авто, которые вполне конкуренты по соотношению цена/качество и давно не представляют «ведро с гайками» как это было еще лет 10-15 назад.

Сейчас отечественное производство и разработка проходят тот же самый путь, с опозданием на 10-15 лет. Да, сначала занимаемся перекраской, потом чем-то чуть более сложным. Но уже сейчас есть вполне самодостаточные вещи.

Но только почему отношение к своему производству у нас остается на уровне: наше – значит фигня. Даже не пытаясь понять и разобраться в сути вопроса?

​​О поддержке

В комментариях затронули тему коммерческой поддержки, мол не сильно она и нужна, если у разработчиков есть нормальная документация, база знаний, сообщество и т.д. и т.п. Отчасти это так, но роль поддержки никогда не следует приуменьшать, особенно если вы только-только начинаете работать с этим продуктом.

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

Также все обращения в поддержку регистрируются, что позволяет впоследствии поднять переписку, особенно в случае сложных случаев или «разбора полетов». Если вы не довольны работой поддержки – вы всегда можете обратиться на линию контроля, где также будет проведен разбор ситуации.

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

А теперь рассмотрим некоторые ситуации. Вы столкнулись с проблемой, возможно, эта проблема уже известна и описана, но вы этого еще не знаете и вам только предстоит это найти.

Поддержка – это гарантированные по времени ответ, возможно он окажется неполным, возможно формальным – но это уже какой-то ответ. Время самостоятельного поиска ограничено только вашим терпением и наличием в сети нужного материала.

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

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

А если это инструкция просто откуда-то перепечатана с кучей ошибок и неточностей – то жди беды.

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

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

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

Сможете ли вы за разумный срок найти такую информацию сами – вопрос отдельный.

Ну и классика жанра – это все знают. Да, все погруженные в тему это знают и подразумевают, что остальные тоже знают по умолчанию. В инструкциях это тоже не отражается, по той же самой причине.

Сообщества? Ну в наших сообществах за такой вопрос над вами, скорее всего, начнут весело глумиться, чем ответят по существу.

Документация, возможно там это есть, точнее там оно точно есть. Но если документация объемная и написана сухим техническим языком – искать в ней придется долго. А целиком документацию перед внедрением вряд ли кто вдумчиво читает. А когда возникли проблемы читать ее тем более некогда.

Так вот, поддержка на такой предельно глупый вопрос вам все равно ответит, потому что работа у нее такая. И если хотя бы просто укажет на главу документации, где это написано – то это уже прогресс.

Да, поддержка неидеальна, как неидеален никто из нас. Она тоже может тупить, отвечать формально и т.д. и т.п., но она обязана привести вас к какому-то решению.

Поэтому поддержкой, если она есть и даже если она платная пренебрегать не стоит, особенно если собственного опыта у вас пока недостаточно.

​​Что будет если мы выполним chmod -R 777 / с правами суперпользователя?

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

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

Поэтому такие службы будут работать до рестарта и более не запустятся, сразу откажут такие утилиты как sudo, также вы не сможете войти с использованием ключа по SSH.

А еще вспоминаем, что 777 – это на самом деле 0777, т.е. легким движением руки мы снесем все SUID, SGID и Sticky bit. После чего откажет большая часть системных утилит и наступит неуправляемый хаос в /tmp.

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

​​Копируй, вставляй и молись

Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».

В переводе данный абзац будет выглядеть так:

Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.

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

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

Спрашиваешь: «а зачем тут это?»

В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.

К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.

Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.

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

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

Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.

Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.

Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.

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

Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.

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

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

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

Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.