Случайно скопипастил json в коммандную строку zsh. Zsh обидился, припух, на внешние раздражители как Ctrl-C реагировать перестал. Думаю, подожду вдруг отвиснет. Но вместо этого он отъел всю доступную память, и был прибит oom-kill-ом. Вопрос: куда теперь посылают баги на Zsh? Нашёл только какой-то старый список багов на sourgeforge десятилетней давности.
Кто угадал, что это новый релиз Kali Linux? https://www.kali.org/blog/kali-linux-2024-4-release/
Что нового:
Для Ъ: кто-то написал предложение в комитет по стандартизации С++ с названием Неопределенного Поведения Вопрос. В нем уличили антисемита, намекнувшего на Еврейский Вопрос. После чего этот человек был выгнан из комитета по стандартизации.
Больше двухсот ответов и 50 с лишним клоунов! Ну, подумаешь, там немножко тупничка было? С кем не бывает. Надо новое правило ввести: если пост набирает 100 ответов, то его сносить уже нельзя. Кто за? Поставьте мне клоуна.
Нашли дыру в Линуксе, которая получила оценку важности 9.9 из 10. Уязвимость имеет характер remote code execution. Детали будут разглашены 30го сентября. Будем готовиться? Запасаться гречкой и рисом.
В чем проблема: на ядре 6.10 btrfs отправляет всю систему в своп при чтении большого количества данных с диска. Я это поймал на ядре 6.10.5, когда делал brfs fi du -s /home/.snapshots/*/snapshot от рута. Причём система в нормальное состояние не возвращается, когда эта операция прекращается, а продолжает тупить. Надо ребутать.
Есть длинное обсуждение на kernel.org, где они там что-то фиксили-фиксили, но недофиксили: https://lore.kernel.org/linux-btrfs/CAL3q7H5zfQNS1qy=jAAZa-7w088Q1K-R7+asj-f++6=N8skWzg@mail.gmail.com/T/
Потом открыли баг: https://bugzilla.kernel.org/show_bug.cgi?id=219121
Говорят, он пофиксен в 6.11-rc4. Но что-то у меня нет в этом уверенности. Откатился на 6.9.9.
Перемещено hobbit из general
На ядре 6.11 всё плохо. Отставание в два раза от ext4 и XFS (листать вниз до geometric mean of all test results):
https://www.phoronix.com/review/linux-611-filesystems/3
Вот ещё куча бенчмарков. БТРfs в одном потоке тоже отстаёт прилично:
https://www.youtube.com/watch?v=_RKSaY4glSc&t=1065s
Bcachefs в одних тестах немного лучше btrfs, а в других хуже.
Я завёл тут себе машину, чтобы на ней виртуалки гонять. Водрузил туда Proxmox (кстати, рекомендую, небо и земля по сравнению со всеми этими virt-manager-ами или gnome boxes-ами).
Ради интереса накатил Kubuntu 24.04. И, внезапно, это оказывается одна из самых лучших легковесных систем для десктопа:
Я думаю, этим всё сказано. Прошу любить и жаловать.
И всем на это положить. Федора объявила о «неделе тестирования доступности». И один человек решил прикинуться слепым и попробовать скринридер, а он оказывается не работает. Более того, он вообще никогда не работал в Вялом. А Вялый в Федоре по-умолчанию уже с 2015 года. Конечно, еще пока можно поставить Xorg, но слепому человеку это будет не под силу, потому что до того, как Xorg установлен, надо видеть куда тыкать мышкой. И вот хороший человек, которому не всё равно, решил сказать об этой проблеме разработчикам. На что они его послали на три буквы посоветовали зафиксить самому. От чего он немного прифигел. Дело тем не кончилось, и он был обозван белым опрессором, угнетателем прав чёрных и заднеприводных. Самые толерантные навалились на него всей толпой. Драма в самом разгаре. Запасайтесь попкорном!
Репозиторий на гитхабе заархивировали. Одна из самых важных програм Линукса канула в лету. Что делать, как жить? Ума не приложу. Как теперь пилить скриншоты???!!!
В Генту решили забанить контрибуции, сгененированные с помощью чатгопоты: ебилды, код, документацию, и т.д.
У них там три причины, но самая главная по-моему:
Quality concerns. LLMs are really great at generating plausibly looking bullshit.
https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg99042.html
Я сейчас читаю обсуждение на hacker news, и там приводятся примеры, где целый проект сгенерён чатгопотой. До чего дошел прогресс, как говорится.
Никогда такого не было, и вот опять!
SDL Developers Weigh Reverting Wayland Over X11 For SDL 3.0
Горорят, что нужен новый протокол:
That is not to say «we should fix FIFO in Mesa/other drivers,» but rather that it is completely unfixable without an additional protocol, in this case fifo-v1.
И что вообще шняга:
There is no advantage to games and average applications preferring Wayland over X11 – only severe performance and unusability regressions right now.
Как же так?
https://felipec.wordpress.com/2024/03/18/stupid-gnome-developers/
В общем, дело было так: один хороший человек, заметил, что терминал гнома не сразу закрывается при выходе из баша. Он им написал фикс в две строчки, но гномики игнорили этого хорошего человека несколько лет, а в баге пытались доказать ему, что он не прав. Но недавно этот хороший человек заметил, что баг всё-таки пофиксили. И как же его пофиксили? - задался он вопросом. И оказалось, что в куче всяких левых изменений был вставлен его фикс из двух строчек. Хорошему человеку это не понравилось, и он написал маленькую статью (на десять страниц) про то, какие же эти гномики редиски. Но потом ему этого показалось мало, и он записал еще маленькое видео (на час), посмотрев которое, уже ни у кого не останется сомнений в том, что гномики просто жалкие и ничтожные люди.
https://beuke.org/terminal-latency/
Самый быстрый по задержке между нажатием кнопки и отображением символа в терминале. В общем, какие результаты? В миллисекундах:
| Terminal Emulator | Min | Max | Avg | Stddev |
|---|---|---|---|---|
| xterm (389-1) | 2.8 | 9.8 | 5.3 | 1.1 |
| alacritty (0.13.1-1) | 5.2 | 17.8 | 6.9 | 1.8 |
| kitty-tuned (0.31.0-1) | 8.1 | 16.3 | 10.7 | 1.4 |
| zutty (0.14-2) | 7.4 | 16.4 | 11.2 | 1.6 |
| st (master 95f22c5) | 11.4 | 17.9 | 14.2 | 1.2 |
Но потом кто-то из ST подсуетился и улучшил среднее время отклика до 5-6 мсек.
А самым последним оказался терминал hyper на жабаскрипте с задержкой ~40мсек.
Будущее, которое мы заслужили.
По ссылке паника при тупой необработке ошибок на расте с помощью unwrap.
https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss
С похмелья после праздничной новогодней недели «longtime Linux developer H. Peter Anvin» открыл свой лэптоп и случайно наткнулся на первоапрельский набор патчей для ядра, где добавляется поддержка С++. «Хм», подумал Петр Анвин, «а это неплохая идея, но где же мое опохмелительное пиво?» И недолго думая, он решил написать в LKML: «У меня сейчас сильно болит башка, поэтому вот предложение для тех, у кого она ещё не болит: а давайте привсунем в ядро C++?» На его предложение уже положительно откликнулись Jiri Slaby из SUSE, а так же David Howells из Red Hat, который и написал эти патчи как шутку 6 лет назад.
И закоммитил в Thorium github репозиторий какие-то непотребные картинки, может быть даже детскую порнографию.
В общем, тем, кто себе поставил этот браузер (я им был), лучше снести его от греха подальше.
Подробности:
https://twitter.com/christitustech/status/1735325168782704652
https://www.youtube.com/watch?v=Q-02fW-n4qg
https://www.reddit.com/r/ThoriumBrowser/comments/18ic3bk/what_happened_to_the_project_and_who_is_alex/
Перемещено Zhbert из desktop
Хочется выставить голую жопу сервис в интернет. Допустим, это просто ssh. Вопрос в том, какой выбрать порт, чтобы дятлы меньше долбились:
Какие ещё есть варианты?
Наконец-то нашел браузер, где ютубчик ускоряется на gpu: Thorium. Устанавливал из rpm (это к тому, что в Appimage может быть по-другому).
Как проверять: заходим на ютубчик, запускаем видос, нажимаем F12 для DevTools, заходим на вкладку Media, там в графе Players ищем запущенный видос, и в Properties/Video Decoder должно стоять VaapiVideoDecoder, Hardware decoder - true.
Считаю, это победа. Ни в каком другом браузере, ни в Chrome, Chromium, Brave, Firefox на моей системе (Fedora и openSUSE) ускорение видео не работало.
С переходом на openSUSE решил пойти вабанк и запрыгнуть на btrfs, но сейчас возникли сомнения, долго ли она протянет? Ведь известно, что btrfs - растение нежное, и в отличие от ext4, её надо иногда поливать, но не слишком часто. Поискав, как правильно ухаживать за btrfs, нашёл вот эти рекомендации: btrfsmaintenance. К моему приятному удивлению, обнаружилось, что они уже интегрированы в openSUSE TW. Там много всяких настроек, но по-умолчанию включены только две: 1) раз в неделю делать btrfs balance, 2) раз в месяц - scrub. Насколько по мнению опытных btrfs-оводов оптимальны эти настройки? Может что-нибудь ещё добавить или, наоборот, отключить?
| следующие → |
