Все очень просто.
Делаем следующее:
- Ставим:
—
obs-studio
— xdg-desktop-portal
- Далее под вашу систему:—
xdg-desktop-portal-gnome для GNOME.xdg-desktop-portal-kde для KDE.xdg-desktop-portal-wlr для wlroots-based Wayland compositors (e.g. Sway, dwl)— И для wlroots композиторов ставим
wlrobs - в идеале с гита.В AUR под ArchLinux есть два пакета
wlrobs - у меня работает на scpy, но просаживает FPS до 25, а dmabuf - в артефактах весь 😬wlrobs-hg - scpy так-же просаживает FPS, но dmabuf заводится и урчит как котенок.Теперь проясню, что это за абра-кодабра.
На Linux есть графический протокол, относительно новый, с кучей плюшек, называется Wayland, но сейчас не про него.
Так вот с ним стримить из OBS из коробки не получится. Надо настраивать.
Тут захват экрана устроен через местный фреймворк PipeWire, а для сего действа требуется разрешение.
Получить его как-раз может OBS через
xdg-desktop-portal, который в свою очередь запросит это разрешение у композитора через плагин. В моем случае это xdg-desktop-portal-wlr.Дальше мы ставим плагин
wlrobs для OBS, чтобы под Sway у нас появились в меню варианты захвата экрана.И всё.
Это первый вброс про линукс. Если будет фидбек - будут еще, но применю все свои "копирайтерские" навыки 🙂
#linux #archlinux #wayland #sway #pipewire
Please open Telegram to view this post
VIEW IN TELEGRAM
👏1
Настроил я себе сегодня сего зверя, оч хорошо выглядит, и автокомплит, и вкладки, и GitHub Copilot подцепил.
И даже... Файловый менеджер, а еще, а еще... 😂 (А еще он бытрый и на Lua)
Читай в телеграфе 😉
#vim #nvim #linux #lua #copilot
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
В линуксе можно встретить такое явление, что первый день недели по умолчанию - воскресенье.
Если вы не сильно интересовались бытом иностранцев, то может выглядеть дико 😅
Я столкнувшись с этим первый раз - подумал:
"Моя неделя начинается в понедельник, я хочу видеть у себя календарь нормального человека".
Читать на хабре
Добро пожаловать в комментарии, дамы и господа! 😂😂😂
Ошибки надо уметь признавать 🤷♂
Please open Telegram to view this post
VIEW IN TELEGRAM
С последнего стрима: использование оперативной памяти на разных операционных системах.
Например Linux с графической оболочкой - после запуска требует всего 300-1500MB
(В зависимости от дистрибутива и загруженности автозапуска)
Windows 10-11 забирает себе, не стесняясь 4-6GB
А в случае с MacOS - почти всю доступную!
К примеру, у меня из 16GB заняты около 8-10GB
(Если у вас меньше 16гб или больше - в эту сторону будет перекос)
И мне тогда пришлось вспомнить механизмы работы с оперативной памятью.
В частности отличия Linux от MacOS
(про Windows сказать с уверенностью не могу, тк ушел с него еще на этапе изучения программирования)
Так вот Linux будет заполнять оперативную память по мере использования, переодически оставляя что-то в кэше, для быстрого доступа к часто используемым данным.
Если память кончается - в первую очередь идет очистка кэша, затем исопльзование SWAP файла.
При этом, как только дело доходит до SWAP файла - по мере его роста ваш компьютер будет превращаться в картофель, каким бы ваш дистрибутив ни был оптимизированным...
Таким образом у меня выходило положить всю систему обычной бесконечной рекурсией javascript в браузере. При этом ядро не падало в ошибку, а просто вставало намертво, и выйти из оконного менеджера в консоль могло занимать по 10 минут, а после перехода в этот "аварийный" режим - уже можно было остановить процесс.
Но даже в этом режиме консоль, которая требует 100-200мб для своей работы, вместе с самим ядрром линукса работали будто такты процессора были заменены на нескольких бухгалтеров 😂
А на MacOS же дела обстоят иначе.
Она анализирует часто исопльзуемые приложения и файлы и знает о том, что вам может понадобиться с большей вероятностю при следующем запуске ОС
(Хранит, естественно локально, но не могу дать гарантии, что ни с кем не делится 😁)
И при запуске системы - сразу же забивает оперативку данными, которые на ее взгляд могут быть вами задействованы.
И именно по этой причине, примеру, если вы дизайнер - после перезагрузки компьютера ваш PhotoShop загрузится за 10 секунд вместо 40 секунд.
Даже в таск менеджере (monitor) у вас не будет шкалы заполнения оперативной памяти. И даже четко не указано число, сколько сейчас использовано.
Тут концепция другая, и эти метрики не подходят.
(Хотя можно посчитать memory used, cached used и swap used)
Актуальная метрика - оценочная степень сжатия памяти (Pressure memory), которая не дает никаких конкретных значений, а лишь график, в котором можно увидеть динамику сжатия памяти и по цвету - размытые пределы этого сжатия.
Так к примеру - пока она зеленая, вообще можно не париться, Если желтая - значит память кончилась, и приходится исопльзовать SWAP, но основные данные, важные для работы OS и основных программ все еще в оперативной памяти, и работать будет не сильно медленнее чем обычно.
И есть еще вариант, когда он становится красным. Честно - ни разу не удалось такого добиться, а значит не этих 16гб хватает сильнее чем 32гб на винде (на линуксе в целом так же как эти 16гб по ощущениям было)
Вот выдержка с оффициального сайта:
Я при импользованых 14GB оперативной памяти догрузил в нее еще модель нейросети, весом 8GB
14+8 = 22GB
Но!
Смотрим график, а там видим сначала рост в желтую зону, с последующим падением обратно в зеленую.
Значит он сначала принял в память новые данные, а когда понял что может понадобиться больше памяти - стал выгружать ненужные данные из памяти.
Через полчаса, пока писал этот пост - все же вернулось обратно в желтую зону, думаю это связано как раз с оптимизацией скорости доступа к данным, чтобы в случае чего важные программы можно было вытащить из кэша, а не заново собирать с диска.
#LongRead #RAM #MacOs #Linux
Например Linux с графической оболочкой - после запуска требует всего 300-1500MB
(В зависимости от дистрибутива и загруженности автозапуска)
Windows 10-11 забирает себе, не стесняясь 4-6GB
А в случае с MacOS - почти всю доступную!
К примеру, у меня из 16GB заняты около 8-10GB
(Если у вас меньше 16гб или больше - в эту сторону будет перекос)
И мне тогда пришлось вспомнить механизмы работы с оперативной памятью.
В частности отличия Linux от MacOS
(про Windows сказать с уверенностью не могу, тк ушел с него еще на этапе изучения программирования)
Так вот Linux будет заполнять оперативную память по мере использования, переодически оставляя что-то в кэше, для быстрого доступа к часто используемым данным.
Если память кончается - в первую очередь идет очистка кэша, затем исопльзование SWAP файла.
При этом, как только дело доходит до SWAP файла - по мере его роста ваш компьютер будет превращаться в картофель, каким бы ваш дистрибутив ни был оптимизированным...
Таким образом у меня выходило положить всю систему обычной бесконечной рекурсией javascript в браузере. При этом ядро не падало в ошибку, а просто вставало намертво, и выйти из оконного менеджера в консоль могло занимать по 10 минут, а после перехода в этот "аварийный" режим - уже можно было остановить процесс.
Но даже в этом режиме консоль, которая требует 100-200мб для своей работы, вместе с самим ядрром линукса работали будто такты процессора были заменены на нескольких бухгалтеров 😂
А на MacOS же дела обстоят иначе.
Она анализирует часто исопльзуемые приложения и файлы и знает о том, что вам может понадобиться с большей вероятностю при следующем запуске ОС
(Хранит, естественно локально, но не могу дать гарантии, что ни с кем не делится 😁)
И при запуске системы - сразу же забивает оперативку данными, которые на ее взгляд могут быть вами задействованы.
И именно по этой причине, примеру, если вы дизайнер - после перезагрузки компьютера ваш PhotoShop загрузится за 10 секунд вместо 40 секунд.
Даже в таск менеджере (monitor) у вас не будет шкалы заполнения оперативной памяти. И даже четко не указано число, сколько сейчас использовано.
Тут концепция другая, и эти метрики не подходят.
(Хотя можно посчитать memory used, cached used и swap used)
Актуальная метрика - оценочная степень сжатия памяти (Pressure memory), которая не дает никаких конкретных значений, а лишь график, в котором можно увидеть динамику сжатия памяти и по цвету - размытые пределы этого сжатия.
Так к примеру - пока она зеленая, вообще можно не париться, Если желтая - значит память кончилась, и приходится исопльзовать SWAP, но основные данные, важные для работы OS и основных программ все еще в оперативной памяти, и работать будет не сильно медленнее чем обычно.
И есть еще вариант, когда он становится красным. Честно - ни разу не удалось такого добиться, а значит не этих 16гб хватает сильнее чем 32гб на винде (на линуксе в целом так же как эти 16гб по ощущениям было)
Вот выдержка с оффициального сайта:
На графике «Нагрузка на память» можно увидеть, насколько эффективно компьютер использует доступную память.
График «Нагрузка на память» имеет зеленый цвет. Компьютер эффективно использует оперативную память.
График «Нагрузка на память» имеет желтый цвет. Компьютеру может понадобиться больше оперативной памяти.
График «Нагрузка на память» имеет красный цвет. Компьютеру нужно больше оперативной памяти.
Я при импользованых 14GB оперативной памяти догрузил в нее еще модель нейросети, весом 8GB
14+8 = 22GB
Но!
Смотрим график, а там видим сначала рост в желтую зону, с последующим падением обратно в зеленую.
Значит он сначала принял в память новые данные, а когда понял что может понадобиться больше памяти - стал выгружать ненужные данные из памяти.
Через полчаса, пока писал этот пост - все же вернулось обратно в желтую зону, думаю это связано как раз с оптимизацией скорости доступа к данным, чтобы в случае чего важные программы можно было вытащить из кэша, а не заново собирать с диска.
#LongRead #RAM #MacOs #Linux
❤2👍1
Cododel.dev | Александр
Наткнулся на видео, в котором раскрыты существенные нюансы по Rust. И я действительно их считаю существенными, потому чо похожий опыт был с фреймворками и другими языками... (Самый банальный пример, но довольно похожий, это React vs Svelte, у второго комьюнити…
🖼️ Бинарники, RUST и JavaScript (Bun)
В комментариях рассказывал, что учил Rust, делая пошаговый эффективный setup сценарий для настройки Ubuntu в качестве веб сервера.
После чего планировалось его собрать в бинарник.
Я нашел нужные библиотеки, разобрался с базовыми принципами работы на Rust, и определил порядок действий и архитектуру проекта, но на этом и остановился, так как подвернулся коммерческий проект.
Так сейчас я вспомнил один факт!
У JavaScript - есть шикарнейшая среда выполнения Bun, предоставляющая еще и набор довольно интерсных инструментов.
Полностью о нём пока не стану рассказывать, суть не в этом, а в возможности компиляции кода в бинарник. При этом, нечто подобное есть и в последних версиях NodeJS в виде патчинга бинарника интерпретатора JavaScript кодом (упоминалось начиная с 16, если не ошибаюсь).
Но в Bun умеет в рантайм исполнения TypeScript без необходимости сборки проекта в JavaScript. А ещё говорят, что есть возможность оптимизации этого TS/JS в байткод.
Но я вижу, что Bun явно в проигрыше по памяти, а производительность и не ставил под сомнение, Rust шустрее.
На скрине можно увидеть, что такой скрипт занимает 20Mb RAM, а сам по себе весит 57Mb:
Но!
Мне никогда и не требовалась производительность. У меня в приоритете скорость и удобство разработки.
А в NPM я помню, есть огромное разнообразие отличных библиотеки для CLI.
И упаковав это всё дело в бинарник весом ±60-120Mb — останется просто его закинуть на сервер, запустить, выбрать что нужно установить, И..(!)
Пойти пить чай на минут 15
(вместо 20-60 минут настройки сервера - мы тратим 5 минут и пьем чай 10-20, и это при наличии опыта, новичкам сильно больше сэкономит времени)
Обязательно сделаю такой инструмент, по идее он сможет привлечь не очень опытных Linux юзеров и собрать вокруг себя комьюнити.😎
#NodeJS #Bun #Rust #JavaScript #TypeScript #Linux
В комментариях рассказывал, что учил Rust, делая пошаговый эффективный setup сценарий для настройки Ubuntu в качестве веб сервера.
После чего планировалось его собрать в бинарник.
Я нашел нужные библиотеки, разобрался с базовыми принципами работы на Rust, и определил порядок действий и архитектуру проекта, но на этом и остановился, так как подвернулся коммерческий проект.
Так сейчас я вспомнил один факт!
У JavaScript - есть шикарнейшая среда выполнения Bun, предоставляющая еще и набор довольно интерсных инструментов.
Полностью о нём пока не стану рассказывать, суть не в этом, а в возможности компиляции кода в бинарник. При этом, нечто подобное есть и в последних версиях NodeJS в виде патчинга бинарника интерпретатора JavaScript кодом (упоминалось начиная с 16, если не ошибаюсь).
Но в Bun умеет в рантайм исполнения TypeScript без необходимости сборки проекта в JavaScript. А ещё говорят, что есть возможность оптимизации этого TS/JS в байткод.
Но я вижу, что Bun явно в проигрыше по памяти, а производительность и не ставил под сомнение, Rust шустрее.
На скрине можно увидеть, что такой скрипт занимает 20Mb RAM, а сам по себе весит 57Mb:
setInterval( () => {
console.log(Date.now());
}, 1000);
Но!
Мне никогда и не требовалась производительность. У меня в приоритете скорость и удобство разработки.
А в NPM я помню, есть огромное разнообразие отличных библиотеки для CLI.
И упаковав это всё дело в бинарник весом ±60-120Mb — останется просто его закинуть на сервер, запустить, выбрать что нужно установить, И..(!)
Пойти пить чай на минут 15
(вместо 20-60 минут настройки сервера - мы тратим 5 минут и пьем чай 10-20, и это при наличии опыта, новичкам сильно больше сэкономит времени)
Обязательно сделаю такой инструмент, по идее он сможет привлечь не очень опытных Linux юзеров и собрать вокруг себя комьюнити.
А ещё, для шарящих —бонусом к Cursor я взял в работу проект, на котором будет расширение для бразуера на React в WXT и бекендом на AppWrite
Так что будет чего интересного рассказать и обсудить
#NodeJS #Bun #Rust #JavaScript #TypeScript #Linux
Please open Telegram to view this post
VIEW IN TELEGRAM