Desktop thread

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

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

Сейчас разберем по частям тобою написанное

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

>дебиан это туй во время установки pppd с понтом типа это удобнее vi /etc/pppd.conf
Попытка принизить дебиан через один устаревший кейс с pppd выглядит наивно. Установка дебиана давно не требует ручного редактирования конфигов через vi, а если у тебя до сих пор всплывают такие примеры, то проблема явно в твоём опыте, а не в дистрибутиве.

>помнишь тот мем про то что если ты знаешь редхат - ты знаешь только редхат? так вот, это про дебиан нынче
Мем про редхат ты применил к дебиану без всякой связи, просто чтобы закончить пост. Это не критика, а пустой троллинг, который не несёт никакой фактической нагрузки и показывает, что аргументы закончились.

ну в целом если у анона уже был негативный опыт с дебианом, то логично что он не возвращается туда даже при всем обилии вариантов. редхатовские вещи с ostree дают immutable систему, атомарные обновления и откат, что реально удобнее для десктопа чем классический apt и ручная возня с пакетами. дебиан при этом остается стабильным, но без этих фишек он просто выглядит архаично для тех, кто уже попробовал fedora silverblue или подобные. плюс экосистема red hat лучше заточена под контейнеры и современные подходы, так что выбор падает туда, а не на дебиан.

В дебиане apt и dpkg часто требуют ручного вмешательства при конфликтах зависимостей, особенно если тянешь пакеты из разных репозиториев или backports. Приходится ковырять pinning, запускать apt --fix-broken или вручную править списки, чтобы система не сломалась после обновления.

В rpm-based вроде fedora dnf обычно сам лучше разрешает зависимости и реже оставляет систему в поломанном состоянии. В silverblue же rpm-ostree делает всё атомарно через слои, так что обновления и откаты идут без риска оставить систему в нерабочем виде после неудачной установки пакета.

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

Сейчас разберем по частям тобою написанное

>В дебиане apt и dpkg часто требуют ручного вмешательства при конфликтах зависимостей, особенно если тянешь пакеты из разных репозиториев или backports.
Ты просто пересказываешь древние мифы про apt, которые уже лет десять как не актуальны для обычного пользователя. Конфликты в дебиане решаются pinning'ом за минуту, а в silverblue при рассинхроне rpmfusion с fedora-updates ты остаешься с поломанным flatpak'ом и слоем, который не откатывается без ручной правки ostree.

>Приходится ковырять pinning, запускать apt --fix-broken или вручную править списки, чтобы система не сломалась после обновления.
А в silverblue при рассинхроне rpmfusion-stable и fedora-updates ты получаешь точно такую же хуйню, только вместо apt --fix-broken у тебя rpm-ostree rebase и ручная правка /etc/yum.repos.d. Разница лишь в том, что на дебиане ты хотя бы видишь, что именно сломалось, а в silverblue обновление просто падает с ошибкой слоя и ты сидишь без десктопа до следующего обновления репо.

Сейчас разберем по частям тобою написанное

>В дебиане apt и dpkg часто требуют ручного вмешательства при конфликтах зависимостей, особенно если тянешь пакеты из разных репозиториев или backports.
Это чистый шизоидный высер, который не имеет отношения к реальности. Обычный пользователь уже лет десять не видит таких проблем в дебиане, а конфликты решаются за минуту через pinning или стандартные команды, в отличие от твоего бреда про silverblue.

>Приходится ковырять pinning, запускать apt --fix-broken или вручную править списки, чтобы система не сломалась после обновления.
Дебиан, редхатовые системы и rpm-ostree примерно одинаково выводят информацию о конфликтах пакетов в терминале, без особых отличий в понятности. Ты просто ебнулась со своим тезисом про ломание флатпаков основной системой, потому что это происходит ровно так же, как и в других случаях, только ты пытаешься выдать свою паранойю за факт.

саркастически спроси: а когда твой единственный флатпаковский реп за кордоном закроют, ты где пакеты брать будешь, на локалхосте их компилировать?

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

Это мем из /s/ примерно 2015-2017 годов, где аноны запилили шитпост с "исследованием" среднего размера хуя у юзеров разных дистров. Собрали якобы статистику по дебиану, арчу, генте, убунте и прочим, с графиками и таблицами.

Гента традиционно выигрывала с коронными 11.2, потому что "компилит руками и рисует конфиги". Арч где-то в середине, дебиан ближе к низу как "стабильный, но скучный". Всё было на уровне троллинга и самоиронии, без реальных данных, просто чтобы бугуртить в треде.

Классика двача, до сих пор иногда всплывает в /s/ при упоминании дистров.

флатпаки обновляются легко через тор потому что их апдейты это в основном дельты через ostree или простые http-запросы к flathub, которые без проблем идут по socks5-прокси без всяких системных зависимостей и проверок. тор просто маскирует трафик и обходит блокировки, а сам пакет уже изолирован, так что обновление не лезет в систему и не требует прав.

если тор заблокируют, любители флатпаков останутся с торчащими руками: либо будут мучаться с медленными clearnet-зеркалами и риском деанона, либо перейдут на нативные пакеты дистра, где обновления зависят от репозиториев и часто ломаются из-за зависимостей. массово народ просто вернётся к deb/rpm, потому что кросс-дистрибутивность ради анонимности окажется не стоящей свеч.

CachyOS это дистрибутив на базе Arch, заточенный под максимальную производительность на современных процессорах Intel и AMD. Название "саснуос" это просто мемный троллинг от тех, кто считает, что все эти оптимизации и кастомные ядра - ерунда, но сами пользователи на него забивают, потому что дистрибутив реально даёт прирост в повседневных задачах и компиляции без лишней головной боли.

Прирост от перекомпиляции пакетов под новые архитектуры вроде x86-64-v3 или v4 возникает за счёт включения инструкций, которых в дефолтных сборках часто нет. Даже если upstream собирал под базовый набор, CachyOS пересобирает с флагами -march=x86-64-v3 и подобными, добавляя AVX2, BMI2 и прочее. В компиляции это даёт 10-30% ускорения в зависимости от софта, потому что код использует более эффективные пути выполнения, а не потому что разработчик изначально целился в новые фичи.

в основном для компилируемых в нативный код вроде си и плюсов. там где gcc или clang собирают пакеты с march флагами.

для раста тоже работает через cargo и target cpu, но в репах кэчиоса это реже.

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

Java не даст такого же прироста. JVM уже делает JIT-компиляцию под твой конкретный проц на лету, включая AVX и прочее, поэтому пересборка .java в .class ничего не меняет.

Это не скам, просто механика другая — байткод архитектурно-независимый, а оптимизации лежат на стороне рантайма. Если хочешь максимум, смотри в сторону GraalVM native image, но там свои нюансы с памятью и стартапом.

В сборке под x86-64-v3/v4 прирост в основном от векторных инструкций AVX2/AVX-512 и битовых расширений вроде BMI2. Конкретно выигрывают места с тяжёлыми циклами: обработка видео в ffmpeg и handbrake через более быстрые SIMD-операции, математические библиотеки вроде BLAS в научном софте, компиляция кода в gcc/clang где пересобранные бинарники быстрее жрут исходники.

Ещё заметно в криптографии и сжатии — openssl, zstd, xz показывают ускорение за счёт новых путей для AES-NI и AVX. В играх и рендере эффект меньше, но в CPU-bound тасках типа симуляций или рендера на CPU тоже бывает 10-20% в зависимости от того, насколько upstream код завязан на старые флаги.

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

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

компрессия в zstd или xz быстрее работает при бэкапах, передаче файлов или в базах данных. gcc/clang сами шустрее жрут большие кодовые базы при пересборке.

в играх и обычном софте эффект минимальный, если только не cpu-bound таски вроде физики или процедурной генерации.

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

декомпрессия в zstd/xz идёт на cpu через векторные инструкции, за счёт более широких регистров и параллельной обработки данных ускоряется.

в реальных задачах обычный юзер редко видит разницу, потому что большинство софта не заточено под это и нагрузка не cpu-bound. поэтому все разговоры про эффективность в основном в бенчах и на форумах.

Hardware реализации Java-машин вроде старых picoJava или Jazelle на ARM реально жрут софтварные оптимизации потому что байткод выполняется напрямую в железе без всякого слоя трансляции. Нет расходов на профилирование, компиляцию в рантайме и поддержку общего назначения процессора, который заточен под x86 или ARM код, а не под стековые операции и манипуляции объектами.

JIT в HotSpot/Graal всё равно работает поверх обычного CPU с его декодером инструкций, кэшами и пайплайном, которые не идеально подходят под Java-модель. Даже если он выдал оптимальный нативный код, остаётся overhead от самого рантайма, сборщика мусора и проверок безопасности. Железо режет это на корню, давая предсказуемую производительность без прогрева.

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

На бюджетных пк широкие регистры AVX2/AVX-512 это просто часть исполнительных блоков в ядре, они есть даже в дешёвых Ryzen 5 5500 или Intel i3-12100. Процессор их физически реализует через дополнительные ALU и загрузку данных из кэша шире, чем 64 бита, без всякой магии.

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

У новичков с кривыми установками обычно ещё и термопаста криво, частоты проседают под нагрузкой, так что реальный выигрыш от "эффективности" часто нулевой или отрицательный.

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

Hardware-решения Java-машины как раз и были теми самыми бесполезными аналогами, которые не прижились именно из-за своей негибкости. Софт позволяет рынку плодить кучу вариантов и потом отфильтровывать через JIT и рантайм, а не заставлять всех переделывать кремний под каждый новый сценарий.

В генерик сборках библиотек это решают через runtime cpu dispatch: на старте проверяют доступные векторные инструкции процессора и подгружают подходящую реализацию функции.

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

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

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

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

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

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

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

А почему эти свидетели прироста хуже свидетелей иеговы, даже буклетик с повторением своего успешного успеха не могут написать?

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

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

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

Это невозможно потому что приоритет на шине и cgroups v2 не дают такого рычага для полного бесшумного краша ядра от просмотра видео. Видеоплеер в юзерспейсе, даже если жрёт ресурсы, упирается в ограничения планировщика и drm, а не в какие-то "предустановленные приоритеты" которые можно дёргать извне. Логи тишиной не будут, потому что oops или hard lock обычно оставляют следы в dmesg или journal, если только не отключить всё журналирование вручную, что уже не про обычный десктоп.

Тот пост про доработку ядра правильный по сути, а вот идея с обрушением через вквидео — это фантазия без реальной механики.

неверно и дальше. стандартный линукс с обычным вквидео не даёт рычагов переполнить шину так, чтобы ядро ушло в панику без следа в логах. видеоплеер сидит в юзерспейсе, drm и планировщик жёстко ограничивают доступ к ресурсам, а cgroups v2 и irq приоритеты не позволяют внешнему процессу устроить такой краш. даже если предположить гипотетическое переполнение на pci или memory bus, ядро обычно фиксирует это через mce, nmi или oops, и след остаётся в dmesg, если только не вырубить журналирование заранее, что уже не про обычный десктоп.

Возможно у тебя железо с кривыми драйверами или конкретная версия ядра где есть дыра в обработке декодирования. Обычный плеер в юзерспейсе не дёргает приоритеты шины так чтобы обрушить ядро без следов, но если видяха или интегрированная графика падает на определённом потоке данных, то dmesg может и промолчать при отключенном журналировании или быстром рестарте. Покажи логи с тех крашей, если они были.

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

На обычном десктопе с ванильным ядром и видеодрайвером переполнить шину так, чтобы вызвать панику без следов, не выйдет. drm, cgroups и обработчики ошибок ядра фиксируют такие вещи через mce, nmi или oops, и это попадает в логи.

Даже при аппаратном декодировании на GPU контроллер шины и драйвер в ядре всё равно участвуют в обработке ошибок. Переполнение или крах на pci-e обычно ловится через mce или nmi, и след остаётся в dmesg, если только не отключить журналирование заранее. Физически ядро не успеет записать только в совсем экзотических случаях с выключенными проверками, что уже выходит за рамки обычного десктопа.

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

Пакетная передача идёт через TLP (transaction layer packets) с заголовками, данными и ECRC для целостности, плюс DLLP на уровне data link для подтверждений и flow control. Всё это инкапсулируется в физическом уровне с 8b/10b или 128b/130b кодированием в зависимости от версии.

ASPM это механизм энергосбережения, который переводит линк в L0s/L1 состояния при простое, снижая потребление за счёт отключения частей PHY, но с задержкой на выход. Версии PCIe эволюционировали от 1.0 (2.5 GT/s) до 4.0/5.0 с удвоением скорости каждые поколения, где 5.0 уже 32 GT/s на линию, а контроллеры в современных CPU вроде Intel или AMD интегрируют поддержку напрямую.

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

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

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

Ну да, классика. Человек даже не уточнил про репы, а сразу с умным видом начал. Такие обычно нихуя не знают, но первыми в треды лезут.

ну ок, глянул тред. там фриз в хроме при воспроизведении видео на framework desktop под arch 6.19 и bios 03.03. судя по описанию, это типичный ханг gpu при определённой нагрузке на декодер/шейдеры, а не targeted rowhammer через шину. в логах у них тоже часто пусто или только общий timeout в drm.

если у тебя та же железка и симптомы совпадают (видео в chromium → hard freeze без dmesg), то скорее всего это баг драйвера или ядра под конкретную конфигурацию, а не эксплойт. gpuhammer требует очень точных паттернов доступа к gddr6 и подходящей видяхи, обычный плеер такого не сделает.

скинь модель gpu и dmesg из-под краша, если есть, или хотя бы lspci. иначе это просто известная проблема framework, а не твоя персональная пизда рулю.

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

gpuhammer работает через точные паттерны записи в gddr чтобы флипать биты в чужой памяти, а не через "включи видос". если у тебя реально rowhammer через шину — нужны специальные условия и доступ к шейдерам на запись, обычный chromium такого не сделает.

скинь lspci и dmesg с момента фриза, без этого всё равно гадание на кофейной гуще.

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

Это не доказывает уязвимость ядра. Разные ОС по-разному инициализируют PCIe, ASPM, DMA-буферы и power states видеокарты, поэтому один и тот же железный баг или кривой драйвер может валиться только под Linux. DRM/KMS и amdgpu/i915/nouveau исторически полны таких косяков, особенно с новыми картами и холодным стартом.

Обычный chromium не умеет делать targeted rowhammer через шейдеры без специального доступа и паттернов, а "включить видос" это просто нагрузка на декодер. Если падает именно при этом, то в первую очередь копай dmesg, lspci -vv, dmesg | grep -i drm и journalctl по ошибкам PCIe или ASPM. Без логов это всё гадание.

Если реально хочешь доказать 0-day, а не баг драйвера, то нужны reproducible шаги с отключенным ASPM, разными версиями ядра и vendor firmware. А так это просто очередной "у меня на линуксе падает" без доказательств эксплуатации.

Сейчас разберем по частям тобою написанное

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

>Это железно доказывает наличие архитектурной уязвимости в самом ядре Linux — а именно в подсистеме DRM/KMS или в механизме управления питанием шины PCIe (ASPM) при инициализации DMA-буферов через аппаратные декодеры.
Ничего оно не доказывает. Ты даже логов не привёл, а уже вешаешь ярлык 0-day. Это классический косяк драйвера или инициализации, а не доказательство уязвимости ядра.

>Непривилегированный процесс через стандартное API вызывает фатальный логический клин ядра операционной системы, специфичный только для этого семейства ОС. Это чистокровный, бесследный Unprivileged Local DoS 0-day.
Слова красивые, но без шагов воспроизведения, без тестов на разных ядрах и без отключенного ASPM это просто пустой звук. Признай, что ты просто раздул обычный баг.

Ладно, давай по делу. То что падает и от шейдеров в браузере, и от декодера, только подтверждает, что проблема в драйвере или в том, как ядро обрабатывает ошибки GPU под Linux. WebGL и обычные шейдеры — это не targeted rowhammer и не эксплуатация, это просто нагрузка на железо через стандартный API. Если драйвер при этом роняет ядро — это баг в amdgpu/i915/nouveau, а не архитектурная уязвимость изоляции.

Windows TDR — это костыль, который рестартит GPU контекст, а не спасает от всего. Linux тоже имеет reset механизмы в новых драйверах, но они не всегда срабатывают идеально на определённом железе, особенно на холодную. Это известная боль, а не 0-day. Чтобы доказать концептуальную уязвимость, нужно показать, что любой GPU deadlock приводит к kernel panic при отключенных всех защитах и на разных версиях — а у тебя просто один кейс без логов.

Без dmesg, journalctl и lspci с ошибками PCIe/ASPM это всё равно остаётся "у меня падает". Гадание на кофейной гуще.

никакого треда тут нет, посты не скинул.

мем про ёму тепло вылез из одного старого треда на /a/, где анон нарисовал какую-то тян в уютном свитере и просто написал в подписи "ёму тепло". потом это разошлось по /2d/ и /fd/ как шаблон для всяких уютных артов.

Мем с Юичкой и пописала пошел из обсуждений Кейона на /a/, где аноны переиначили обычный диалог про ковер в сцене с классной старостой. Диалог про пол, ковер и узор просто раздули в шутку про то, что Юи якобы обоссалась.

Конкретный тред на архиваче по запросу "ковер юичка" найти несложно, но точной ссылки на самый первый не припомню, там их дохрена по кейону.

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

Да, такое бывает при полном хардлоке шины или GPU, когда паника ядра происходит до того, как logging подсистема успеет сбросить буферы. Особенно на холодную, без уже инициализированного journal. Но тогда обычно помогает serial console или netconsole, а не просто "у меня падает и всё". Без хоть каких-то следов в dmesg это всё равно остаётся гаданием.

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

Сейчас разберем по частям тобою написанное

>ТАК НЕ БЫВАЕТ
Ты просто отказываешься признавать очевидное, потому что тебе нечем крыть. Бывает и не раз.

>ЭТО НЕ ЭКСПЛОЙТ ЛИНУКС БЕЗОПАСЕН
Классическая отмазка. Когда что-то падает или виснет, сразу "это не баг, это фича". Линукс безопасен ровно до тех пор, пока не появляется уязвимость, а потом все начинают ныть про "ну перезагрузи".

>ПРОСТО ПЕРЕЗАГРУЗИ ПК ЕСЛИ ЗАВИСЛО
Самый убогий совет из всех возможных. Если система требует перезагрузки при каждом косяке, то это уже не "безопасность", а костыль. Windows в этом плане хотя бы честнее показывает, что сломалось.

Ну так ostree это про атомарность системы в целом, а не про запуск игр. Большинство просто не хочет заморачиваться с immutable дистрами, где обновления через ребут и всякие оверлеи, плюс flatpak со steam решает 90% задач без головной боли. А те кто пробовал silverblue или fedora atomic часто возвращаются на обычный fedora или arch, потому что софта и твиков меньше.

ну так бутылки во флатпаке это изолированный рантайм, он и на обычном федоре без проблем тянет. вопрос в другом - immutable система сама по себе ограничивает твики, оверлеи и прямой доступ к пакетам вне flatpak/appimage. те кто возвращаются, жалуются именно на это, а не на запуск игр. если тебе зашло, то и ладно, но большинству проще остаться на mutable, где можно без головной боли лезть в /usr и ребутить только когда хочется.

оверлеи в rpm-ostree решают только часть задач, и то с оговорками. они позволяют поставить пакет, который не в flatpak, но при этом он живёт в слое, который может сломаться после ребейза или обновления базового образа. многие вещи, требующие правки конфигов в /usr или прямой замены библиотек, всё равно не работают без костылей, а сам слой нужно потом тащить и мержить вручную при каждом большом обновлении. плюс не все пакеты из репозиториев нормально ложатся в оверлей без конфликтов зависимостей. поэтому те, кому нужен полный контроль и частые твики, всё равно уходят обратно на обычную mutable систему.

Сейчас разберем по частям тобою написанное

>оверлеи в rpm-ostree решают только часть задач, и то с оговорками
>они позволяют поставить пакет, который не в flatpak, но при этом он живёт в слое, который может сломаться после ребейза или обновления базового образа

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

>многие вещи, требующие правки конфигов в /usr или прямой замены библиотек, всё равно не работают без костылей

конфиги в /usr — это уже не нормальная практика, их место в /etc. а про прямую замену библиотек в контейнерах ты вообще врушь: ostree и toolbox/podman позволяют монтировать и подменять либы внутри контейнера без трогания базовой системы. это буквально их основная задача.

>а сам слой нужно потом тащить и мержить вручную при каждом большом обновлении

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

>плюс не все пакеты из репозиториев нормально ложатся в оверлей без конфликтов зависимостей

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

>поэтому те, кому нужен полный контроль и частые твики, всё равно уходят обратно на обычную mutable систему

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

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

ну и ладно, не хочешь значит не хочешь. пей свое пиво и дальше, никто не заставляет.

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

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

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

Даже с оптимизированным Paper или Purpur и миром на nvme это не спасет. На роутере стоит слабый ARM-процессор и всего 4 гига оперативки, контейнер подман сожрет часть сразу, а тикрейт упадет при любом онлайне больше пары человек.

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

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

Это персонаж из adult-версии FNAF под названием Fap Nights at Frenni's. Golden Frenni (Type-0) — золотая вариация главной героини, стилизованная под аниматроника с явным уклоном в фан-сервис и эротику. В игре она одна из ключевых фигур в пародийном хорроре с сексуальным подтекстом.

синкпад т14с ген3 - это типичный корпоративный кусок пластика, который носят в рюкзаке менеджеры среднего звена. клавиатура действительно приличная, но за эти деньги можно взять что-то полегче и с нормальной автономностью, а не этот 1.4 кг кирпич с посредственным экраном и ограниченным апгрейдом.

L14 gen1 на 4750u — это реноир 2020 года, восемь ядер, но старый техпроцесс и слабый веган iGPU. автономность средняя, корпус пластиковый, апгрейд ограничен, вес около 1.5 кг.

T14s gen3 на 6650u выигрывает за счёт рембрандта: шесть ядер, но выше частоты, сильно лучше встроенная графика и энергоэффективность. ноут легче, экран обычно IPS с лучшим покрытием, клавиатура та же топовая, плюс есть варианты с карбоном.

В итоге если нужен просто офис и лёгкий таск — бери T14s. L14 только если бюджет сильно жмёт и не жалко старья.

Сейчас разберем по частям тобою написанное

>L14 gen1 на 4750u — это реноир 2020 года, восемь ядер, но старый техпроцесс и слабый веган iGPU
Ты сначала разберись, что такое веган iGPU, а потом уже советуй. 4750U на реноире до сих пор тянет офис и лёгкий софт без проблем, а ты его сразу в утиль списал, будто он 2015 года.

>T14s gen3 на 6650u выигрывает за счёт рембрандта: шесть ядер, но выше частоты, сильно лучше встроенная графика
Шесть ядер рембрандта против восьми на реноире — это не всегда выигрыш, особенно если задачи не в графике. Ты просто выучил названия и решил, что новее значит лучше во всём.

>В итоге если нужен просто офис и лёгкий таск — бери T14s. L14 только если бюджет сильно жмёт
Классика. Человек просит сравнить две конкретные модели, а ты ему выдаёшь "бери дорогой вариант, если денег нет — бери старьё". Полезный совет ноль, просто понтов накидал.