16,1 Мб, mp4,720x1280, 0:45
500 Кб, 1920x1920>>8738 (OP)
Реквестую этот пик на следующий перекат.
Реквестую этот пик на следующий перекат.
Пытаюсь запустить IDE внутри WSL. Однако ру айпишники поблочены и скачивать плагины в ней или устанавливать через джетбреинс тулбокс я не могу.
У меня есть xray прокси, спокойно работает на винде
Попробовал накатить https://github.com/rofl0r/proxychains-ng на свою WSL-убунту
Мастдай пишет что я должен использовать адресс своей машины чтобы получить доступ из под WSL'я к виндовым запущенным серверам. Я на первом пике получил, на втором вставил этот сокс в конфигурацию proxychains
Делаю proxychains4 curl ipinfo.io чтобы проверить что все работает:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] Strict chain ... 172.17.208.1:1080 ... timeout
curl: (7) Couldn't connect to server
Не работает.
Если кто-нибудь оборачивал трафик WSL'ки в проксю развернутую на локалке винды, подскажите пж как правильно.
У меня есть xray прокси, спокойно работает на винде
Попробовал накатить https://github.com/rofl0r/proxychains-ng на свою WSL-убунту
Мастдай пишет что я должен использовать адресс своей машины чтобы получить доступ из под WSL'я к виндовым запущенным серверам. Я на первом пике получил, на втором вставил этот сокс в конфигурацию proxychains
Делаю proxychains4 curl ipinfo.io чтобы проверить что все работает:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] Strict chain ... 172.17.208.1:1080 ... timeout
curl: (7) Couldn't connect to server
Не работает.
Если кто-нибудь оборачивал трафик WSL'ки в проксю развернутую на локалке винды, подскажите пж как правильно.
>>8754
Ладно, похуй, зачем я мозг себе ебу, просто все затунелирую нахуй через v2rayN. Какой же долбоеб.
Ладно, похуй, зачем я мозг себе ебу, просто все затунелирую нахуй через v2rayN. Какой же долбоеб.
14 Кб, 977x198>>8756
Нет, я слишком глуп, никак не получается. Была надежда на одну опцию в wsl'е, но она только в винде11.
Нет, я слишком глуп, никак не получается. Была надежда на одну опцию в wsl'е, но она только в винде11.
>>8738 (OP)
Господа нейроёбы, я засунул llamacpp-cli вызывающую 7б модельку внутрь фор лупа и оно стабильно крашит мою память на 3-5 итерации. Какие варианты? Я не хочу поднимать каждый раз сервер и писать скрипт на питоне. Хочу вот так тяп-ляп и чтобы работало.
Господа нейроёбы, я засунул llamacpp-cli вызывающую 7б модельку внутрь фор лупа и оно стабильно крашит мою память на 3-5 итерации. Какие варианты? Я не хочу поднимать каждый раз сервер и писать скрипт на питоне. Хочу вот так тяп-ляп и чтобы работало.
>>8769
Забейте х2, заработало. Хуй пойми как оно в этой виртуалке работает. Такое ощущение что gWSL приложения уже используют мою сеть напрямую.
>>8785
Оно через раз работает v2rayn. Само IDE поставило, а когда плагины пытаюсь искать - интернета нет. Без тунелирования появляются, но блочит при установке.
Забейте х2, заработало. Хуй пойми как оно в этой виртуалке работает. Такое ощущение что gWSL приложения уже используют мою сеть напрямую.
>>8785
Оно через раз работает v2rayn. Само IDE поставило, а когда плагины пытаюсь искать - интернета нет. Без тунелирования появляются, но блочит при установке.
М>>8801
Там виндузятники одни + вопрос абсолютно уместен для тематики треда.
Там виндузятники одни + вопрос абсолютно уместен для тематики треда.
Заебло вычищать говно при новой установке, есть какой способ (для дебила) запиздрячить свою систему на исошку с возможностью установки?
>>8848
Откуда оно там? Просто не устанавливай лишнее и всё
Нааерное как то можно целый образ диска завернуть в iso
>Заебло вычищать говно при новой установке
Откуда оно там? Просто не устанавливай лишнее и всё
>, есть какой способ (для дебила) запиздрячить свою систему на исошку с возможностью установки?
Нааерное как то можно целый образ диска завернуть в iso
Кто еблан: я, makepkg, wiki по aur'у или hyprland?
Вот смотрите, я на archlinux хочу собрать например neovim последней версии из git'a, я делаю clone aur.archlinux.. захожу, делаю makepkg -s, потом pacman -U и всё охуенно. Спустя какое-то время я хочу обновиться до теперь нового последнего коммита. Я смотрю в вики, где надо сделать git pull только там, где PKGBUILD, потом снова makepkg, я так делаю и в консоль пишется updating git, вроде всё хорошо, а на выходе я получаю хуйню. Потому что если я зайду в SRCDIST/neovim (у меня это ~/sources/neovim), и сделаю git status, то мне покажут, что эта рабочая директория 99999 коммитов позади мастера. Почему? Теперь я в ~/sources/neovim делаю git pull, возвращаюсь в папку с PKGBUILD, делаю makepkg -s и всё хорошо, получаю свою нормальную последнюю версию. Почему так? Почему makepkg пишет, что обновляет neovim git repo, а на деле ковыряется в жопе? Почему в вики не написано, что я сам в SRCDIST должен заходить и пулить? Или я что-то не понимаю. Объясните пж.
Ну и немного отвлечено: почему hyprland в ауре разбросан ошметками как после взрыва? hyprland-git, hyprutils-git, hyprcursor-git, hyprlang-git. Пока я не обновлялся высрались ещё какие-то hyprgraphics-git и hypr-qtutils-git бляяяя создайте ещё 100 пакетов прошу. Какого хуя? Может на каждую букву кода по отдельному пакету захуярить?
Вот смотрите, я на archlinux хочу собрать например neovim последней версии из git'a, я делаю clone aur.archlinux.. захожу, делаю makepkg -s, потом pacman -U и всё охуенно. Спустя какое-то время я хочу обновиться до теперь нового последнего коммита. Я смотрю в вики, где надо сделать git pull только там, где PKGBUILD, потом снова makepkg, я так делаю и в консоль пишется updating git, вроде всё хорошо, а на выходе я получаю хуйню. Потому что если я зайду в SRCDIST/neovim (у меня это ~/sources/neovim), и сделаю git status, то мне покажут, что эта рабочая директория 99999 коммитов позади мастера. Почему? Теперь я в ~/sources/neovim делаю git pull, возвращаюсь в папку с PKGBUILD, делаю makepkg -s и всё хорошо, получаю свою нормальную последнюю версию. Почему так? Почему makepkg пишет, что обновляет neovim git repo, а на деле ковыряется в жопе? Почему в вики не написано, что я сам в SRCDIST должен заходить и пулить? Или я что-то не понимаю. Объясните пж.
Ну и немного отвлечено: почему hyprland в ауре разбросан ошметками как после взрыва? hyprland-git, hyprutils-git, hyprcursor-git, hyprlang-git. Пока я не обновлялся высрались ещё какие-то hyprgraphics-git и hypr-qtutils-git бляяяя создайте ещё 100 пакетов прошу. Какого хуя? Может на каждую букву кода по отдельному пакету захуярить?
31 Кб, 1327x41>>8908
Ну и вот как итог два пакета, один после makepkg, второй после ручного git pull и makepkg. Один из них от последнего коммита, другой от хуйни старой с сентября.
Ну и вот как итог два пакета, один после makepkg, второй после ручного git pull и makepkg. Один из них от последнего коммита, другой от хуйни старой с сентября.
>>8903
Не, мне надо по пол года не обновлять, а не каждый день.
Не, мне надо по пол года не обновлять, а не каждый день.
>>8872
У всех современных дистров куча говна по дефолту, ладно, пойду изучать debootstrap.
> Откуда оно там? Просто не устанавливай лишнее и всё
У всех современных дистров куча говна по дефолту, ладно, пойду изучать debootstrap.
Котаны, это правда или нет, что на линуксе, особенно на всяких xfce или puppy linux можно и на всяких core duo почти 20 летней давности сидеть и при 1 гб рам?
Почему про линукс постоянно говорят, что он для слабых компов лучше? Разве винда не лучше оптимизирована?
Телега, браузер с двачем, ютуб на 480p и реддит - для этого и pentium 4 поди подойдёт?
Есть тут аноны с некрожелезом на люниксе?
Какие подводные?
Почему про линукс постоянно говорят, что он для слабых компов лучше? Разве винда не лучше оптимизирована?
Телега, браузер с двачем, ютуб на 480p и реддит - для этого и pentium 4 поди подойдёт?
Есть тут аноны с некрожелезом на люниксе?
Какие подводные?
>>8935
Че лишнее у арча?
Че лишнее у арча?
>>8936
Уменя lxqt занимал чуть ли не десятки мегабайт
Уменя lxqt занимал чуть ли не десятки мегабайт
>>8941 (Del)
Что лишнее у дебиана?
Что лишнее у дебиана?
>>8936
Нет, забудь, опоздал лет на 12, сейчас линупс это неоптимизированная хуйня.
Нет, забудь, опоздал лет на 12, сейчас линупс это неоптимизированная хуйня.
>>8936
artix (runit)+xfce4 в простое жрёт примерно 350мб оперативки, то есть имея 1гб ты можешь свободно браузер запустить с парой вкладок, да ещё и офисную хуйню какую-нибудь типо ворда или экселя, и всё это будет более-менее шустро работать даже на дохлом коредуба. При этом ты имеешь полностью функциональное и вполне удобное окружение рабочего стола, со всякими менюшками, панелями и прочим гуем. Ни одна современная версия виндоус, даже порезанная и вычищенная вилкой банкоматка, на такое не способна в принципе, даже теоретически. И да, кстати, на скорость работы влияет не столько мощность твоего процессора, сколько накопитель. Если у тебя хард, да ещё и какой нибудь ноутбучный, то работать компьютер будет медленно в любом случае.
artix (runit)+xfce4 в простое жрёт примерно 350мб оперативки, то есть имея 1гб ты можешь свободно браузер запустить с парой вкладок, да ещё и офисную хуйню какую-нибудь типо ворда или экселя, и всё это будет более-менее шустро работать даже на дохлом коредуба. При этом ты имеешь полностью функциональное и вполне удобное окружение рабочего стола, со всякими менюшками, панелями и прочим гуем. Ни одна современная версия виндоус, даже порезанная и вычищенная вилкой банкоматка, на такое не способна в принципе, даже теоретически. И да, кстати, на скорость работы влияет не столько мощность твоего процессора, сколько накопитель. Если у тебя хард, да ещё и какой нибудь ноутбучный, то работать компьютер будет медленно в любом случае.
>>8936
Определи, что значит «сидеть», тогда вопрос будет иметь смысл. Одному «сидеть» — бумажки печатать, другому — «ну там в КРУЗИС 13 поиграть иногда, и чтобы в фоне пять говноклиентов говносоциалочек висело для общения с посонами».
Нет, не подойдёт. Если бы ты пробовал что-то делать на четвёром пне, одно только замечание про видео заставило бы тебя кряхтеть (потому что выше ушей в производительности декодирования на процесоре не прыгнуть).
Можно пытаться скачивать в нужном формате и разрешении, но так и на «Амигах» можно смотреть, всего-то используя промежуточный мощный компьютер для конвертирования:
https://www.youtube.com/watch?v=b17w36HVBMg
«Постоянно говорят» о какой-то «легковесности» друг другу ламеры, которым лень что-то делать в реальности, и поэтому они пересказывают друг другу трёп в комментариях и видосиках. Есть конкретные вещи, которые оказывают влияние на удобство работы на слабых системах, от которых можно избавиться, есть другие, от которых никуда не денешься. Точно так же современные ядра не предусматривают совместимость с процессорами времён 486-х не потому, что это заговор, а потому, что это бессмысленно при актуальных требованиях программ к памяти и производительности, а также выборе гораздо более дешёвых и производительных систем для разработки. Глупо конструировать «Камаз», на который в некоторых случаях можно поставить колёса от легковушки, потому что никто и никогда реально не будет это использовать.
Определи, что значит «сидеть», тогда вопрос будет иметь смысл. Одному «сидеть» — бумажки печатать, другому — «ну там в КРУЗИС 13 поиграть иногда, и чтобы в фоне пять говноклиентов говносоциалочек висело для общения с посонами».
> Телега, браузер с двачем, ютуб на 480p и реддит - для этого и pentium 4 поди подойдёт?
Нет, не подойдёт. Если бы ты пробовал что-то делать на четвёром пне, одно только замечание про видео заставило бы тебя кряхтеть (потому что выше ушей в производительности декодирования на процесоре не прыгнуть).
Можно пытаться скачивать в нужном формате и разрешении, но так и на «Амигах» можно смотреть, всего-то используя промежуточный мощный компьютер для конвертирования:
https://www.youtube.com/watch?v=b17w36HVBMg
«Постоянно говорят» о какой-то «легковесности» друг другу ламеры, которым лень что-то делать в реальности, и поэтому они пересказывают друг другу трёп в комментариях и видосиках. Есть конкретные вещи, которые оказывают влияние на удобство работы на слабых системах, от которых можно избавиться, есть другие, от которых никуда не денешься. Точно так же современные ядра не предусматривают совместимость с процессорами времён 486-х не потому, что это заговор, а потому, что это бессмысленно при актуальных требованиях программ к памяти и производительности, а также выборе гораздо более дешёвых и производительных систем для разработки. Глупо конструировать «Камаз», на который в некоторых случаях можно поставить колёса от легковушки, потому что никто и никогда реально не будет это использовать.
>>8738 (OP)
У меня два монитора. Есть такое, что какая-то среда рабочего стола хуже или совсем не подходит для работы с несколькими мониторами? Или все дешки юзабельны плюс-минус одинаково?
У меня два монитора. Есть такое, что какая-то среда рабочего стола хуже или совсем не подходит для работы с несколькими мониторами? Или все дешки юзабельны плюс-минус одинаково?
>>9025
Если они с разной герцовкой - нужна ДЕ поддерживающая waland, т.е. Гном или Кеды крайних версий. Иначе - пофиг.
Если они с разной герцовкой - нужна ДЕ поддерживающая waland, т.е. Гном или Кеды крайних версий. Иначе - пофиг.
>>9025
Если у них разная герцовка/разрешение, то сразу на вялом бери что-то. Если разные цветовые профили, то на тайлоговне больно их настраивать, бери нормисные гном или кеды.
Если у них разная герцовка/разрешение, то сразу на вялом бери что-то. Если разные цветовые профили, то на тайлоговне больно их настраивать, бери нормисные гном или кеды.
>>9033
хайвмайнд
хайвмайнд
Мне нужно зайти и по ссш запустить программу, закрыть ссш, а потом опять подключиться и "зайти в терминал с запущенной командой", чтобы посмотреть, что она вывела. Перенаправить вывод в файл не могу, потому что нужно будет еще вводить что то
>>9063
Спасибо
Спасибо
>>9057
screen неудобное говно мамонта, используй tmux.
screen неудобное говно мамонта, используй tmux.
>>8848
nixos
nixos
62 Кб, 330x402>>9076
погуглил что это и кто разработчик
а потом хуйня с пикрила форматнёт мне диск за русский айпишник и потому что израилю можно а эрефии нельзя. не, лучше уж старый добрый tmux чем стандартный как под копирку высранный суппортер куррент сынга.
погуглил что это и кто разработчик
> фамилия
> прононс
> раст
> сойфейс
а потом хуйня с пикрила форматнёт мне диск за русский айпишник и потому что израилю можно а эрефии нельзя. не, лучше уж старый добрый tmux чем стандартный как под копирку высранный суппортер куррент сынга.
>>8908
Все ебланы, все.
Ты хочешь пользваться штукой, не рассчитанной на простых пользователей, не понимая, что она делает, вбиваешь какие-то команды, о которых нигде не написано, вместо того, чтобы разобраться.
git не является каким-то волшебным автоматическим обновлятором всего. Когда ты вызываешь команду в каталоге с PKGBUILD, тебе копируется содержимое того же репозитория, что и при инициализации, то есть вот эти файлы:
https://aur.archlinux.org/cgit/aur.git/tree/?h=neovim-git
Больше ничего не происходит. С тем же успехом можно просто скачать какой-то архивчик с условного moipaketi.narod.ru и получить исходники и скрипты сборки (четверть века назад так программы и распространяли), но система контроля версий позволяет удобно контролировать и описывать изменения и авторам, и пользователям. Дальше makepkg запускает функции в скрипте.
Посмотрим на него:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=neovim-git
Ничего интеллектуального с версиями и датами он не делает, просто указывает источником исходников https://github.com/neovim/neovim.git и копирует добавленную автором конфигурацию запуска nvimdoc. Следовательно, оно скачивается, копируется во временную папку, собирается.
Отметим надёжную как швейцарские часы процедуру склеивания версии из циферок в cmakelists.txt. Никто не говорит, что так нельзя делать. Однако же, никто не говорит, что так можно и нужно делать. Такой цирк с конями всегда начинается, когда людям предлагается обойтись автоматизацией на bash. Можно полюбоваться на решения в
https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
Казалось бы, люди, взглянувшие на это, должны понять: «Мы все занимаемся какой-то хуйнёй».
Отметим, что AUR в базе данных хранит версию на момент загрузки PKGBUILD и не может показать актуальную, так как был предназначен для рецептов сборки конкретных версий конкретных приложений, а не произвольного кода из «будущего». Также нельзя проверить неизменность постоянно меняющихся файлов, поэтому в хэшах указан SKIP. Понятно, что предполагается, что «Github всегда безопасен», но это уже отдельная тема, которая далеко уведёт, поэтому допустим, что человек, которому понадобился свежий neovim из репозитория на Github, в любом случае доверяет Github, даже если всё проделывает руками.
Следовательно, cmake собирает приложение по представленной в исходниках конфигурации, файлы на выходе пихаются в пакет с нужным названием и метаданными.
Теперь поговорим о самой сборке. Традиционно компиляторы на C не пересобирают объектные модули, которые уже собраны, если для этого нет причин. Понятно, что если сборка библиотек в зависимостях занимает десять минут (или часов), а в программе поменялась одна строчка, хочется, чтобы пересобран был только код программы, чтобы быть заново связанным с готовым всем прочим. Причинами могут являться расхождение между штампом времени в исходниках и с скомпилированной версии или расхождение между новыми и старыми определениями связываемых функций. В зависимости от режима работы, компилятора, системы сборки (бегающей вокруг, проверяющей файлы и тыкающей им во время изменения, тыкающей в компилятор и так далее) на исходники могут и вовсе не смотреть, если найден готовый файл с кодом для этого модуля (как уже сказано, это желаемое поведение в большинстве случаев). За всё это приходится платить усложнением конфигураций и непонятными ошибками, которые возникают, когда неактуальные версии старых модулей собираются с обновлёнными (в случае несовпадения заголовков сборка сразу упадёт, и это хорошо, потому что хуже, когда код молча собирается и делает вовсе не то, что ожидается). Также возникают вопросы параллелизации сборки и построения её порядка. В развесистых проектах, на нескольких языках и прочем, заданию того, куда правильно нужно пнуть при обновлении такого-то исходника, модуля, интерфейса, файла данных и так далее, чтобы всё собралось, посвящены километры конфигурационных файлов.
В современных языках и системах сборки можно просто задать соответствие между артефактом abcd... и артефактом 6789..., и тогда, например, скачивание отличающейся версии какого-то кода из репозитория однозначно запустит цепочку изменений. В наследии полувековой давности за корректность отвечает функция системы сборки clean (иногда в нескольких вариантах). Да, то самое заклинание make clean. Эта конфигурация удаляет все временные (сгенерированные компилятором) файлы и заставляет пересобрать код, перегенерировать ресурсы, если нужно, и так далее. В древних системах файлики для удаления перечисляли авторы, потом системы стали помогать автоматизировать эту функцию, распихивая всё по отдельным каталогам. Если код логично разбит на модули (например, библиотеки и программа, их использующая, хотя и она может состоять из множества модулей), так можно очистить и пересобрать только нужные, не тратя время на остальные. И наоборот, в некоторых проектах висят огромные предупреждения, что на частичную сборку после частичных изменений их конфигурация не рассчитана, и сообщения об ошибках от людей, не запустивших make clean перед сборкой для обновления всего-всего, никем рассматриваться не будут.
Ты совершенно зря лезешь в какие-то подпапки и руками что-то достаёшь из репозитория. Система автоматизированная, это должно происходить само. Если не происходит, то либо авторы что-то неправильно делают, либо ты. Вероятно, даже то, что тебе что-то удалось пересобрать, является побочным эффектом. Например, какой-то кусок системы сборки обнаружил, что файлы теперь принадлежат текущему пользователю, и даты изменил при переприсвоении, что-нибудь в этом духе.
Почитаем маны:
https://man.archlinux.org/man/PKGBUILD.5
Вроде ничего про очистку результатов компиляции.
https://man.archlinux.org/man/makepkg.8.en
А вот тут есть и --clean, и --cleanbuild. Попробуй, посмотри, что они делают.
Это не пакеты. Пакет — это то, что ты получаешь в результате и можешь легко и просто установить на одну систему, сто систем, тысячу, и так далее. Возможно, с какими-то изменениями, важными для устройств или сетей, которые ты администрируешь. А это рецепты сборки пакетов.
Никому не запрещено подготовить единый общий пакет, который сам всё из всех репозиториев достанет, распихает, соберёт и получит результат (очевидно, стабильную версию так и получают). Однако перечисленные тобой модули просто повторяют устройство репозиториев в проекте, и используются, скорее всего, людьми, уже знакомыми с тем, что и как от чего зависит, что совместимо, и как должно быть собрано. Эта информация у них в голове, а AUR просто помогает готовыми командами получить свежую сборку. Если же делать общий пакет, то автору придётся пристально следить за развитием кода, выбирать заведомо рабочие и совместимые коммиты, сидеть в чатике разработчиков и реагировать на сообщения «я тут попробую ошибку решить, но может начать падать на всех прочих версиях OpenGL», чтобы не собирать заведомо нерабочую программу. Понятно, что тут дохрена работы, и если кто-то из разработчиков сам не отмечает рабочие тестовые конфигурации, то рабочая работа работает работу маловероятно, что кто-то из волонтёров пожелает сидеть и каждый день заниматься только этим. Один из вариантов решения — автоматические сборки без гарантий, «если сегодняшняя тестовая версия падает — не повезло, возьмите вчерашнюю». Другой вариант — требование вести разработку и тестирование в отдельных ветках, чтобы основной репозиторий всегда содержал корректную версию кода. Если нет ни того, ни другого, то проект предлагает внешним пользователям только стабильные версии, и обо всём остальном не нужно делать никаких предположений (или не предлагает вообще никаких, как ffmpeg когда-то, в результате чего люди решили, что этот пиздец продолжаться не может, и сделали форк). Вот какая жизненно необходимая функция появилась в neovim в последние месяцы, что тебе срочно понадобилось собрать самое свеженькое? Если ты думаешь, что ща модно рэп, йоу, и все крутые пацаны в интернете делают это просто так, без особой нужды, то ты жертва моды. Если ты следишь за разработкой и хочешь посмотреть на новые возможности или исправления ошибок, то ты, по факту, внештатный тестер. Молодец, но тогда надо лучше понимать, как обращаться с нестабильными версиями.
Все ебланы, все.
Ты хочешь пользваться штукой, не рассчитанной на простых пользователей, не понимая, что она делает, вбиваешь какие-то команды, о которых нигде не написано, вместо того, чтобы разобраться.
git не является каким-то волшебным автоматическим обновлятором всего. Когда ты вызываешь команду в каталоге с PKGBUILD, тебе копируется содержимое того же репозитория, что и при инициализации, то есть вот эти файлы:
https://aur.archlinux.org/cgit/aur.git/tree/?h=neovim-git
Больше ничего не происходит. С тем же успехом можно просто скачать какой-то архивчик с условного moipaketi.narod.ru и получить исходники и скрипты сборки (четверть века назад так программы и распространяли), но система контроля версий позволяет удобно контролировать и описывать изменения и авторам, и пользователям. Дальше makepkg запускает функции в скрипте.
Посмотрим на него:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=neovim-git
Ничего интеллектуального с версиями и датами он не делает, просто указывает источником исходников https://github.com/neovim/neovim.git и копирует добавленную автором конфигурацию запуска nvimdoc. Следовательно, оно скачивается, копируется во временную папку, собирается.
Отметим надёжную как швейцарские часы процедуру склеивания версии из циферок в cmakelists.txt. Никто не говорит, что так нельзя делать. Однако же, никто не говорит, что так можно и нужно делать. Такой цирк с конями всегда начинается, когда людям предлагается обойтись автоматизацией на bash. Можно полюбоваться на решения в
https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
Казалось бы, люди, взглянувшие на это, должны понять: «Мы все занимаемся какой-то хуйнёй».
Отметим, что AUR в базе данных хранит версию на момент загрузки PKGBUILD и не может показать актуальную, так как был предназначен для рецептов сборки конкретных версий конкретных приложений, а не произвольного кода из «будущего». Также нельзя проверить неизменность постоянно меняющихся файлов, поэтому в хэшах указан SKIP. Понятно, что предполагается, что «Github всегда безопасен», но это уже отдельная тема, которая далеко уведёт, поэтому допустим, что человек, которому понадобился свежий neovim из репозитория на Github, в любом случае доверяет Github, даже если всё проделывает руками.
Следовательно, cmake собирает приложение по представленной в исходниках конфигурации, файлы на выходе пихаются в пакет с нужным названием и метаданными.
Теперь поговорим о самой сборке. Традиционно компиляторы на C не пересобирают объектные модули, которые уже собраны, если для этого нет причин. Понятно, что если сборка библиотек в зависимостях занимает десять минут (или часов), а в программе поменялась одна строчка, хочется, чтобы пересобран был только код программы, чтобы быть заново связанным с готовым всем прочим. Причинами могут являться расхождение между штампом времени в исходниках и с скомпилированной версии или расхождение между новыми и старыми определениями связываемых функций. В зависимости от режима работы, компилятора, системы сборки (бегающей вокруг, проверяющей файлы и тыкающей им во время изменения, тыкающей в компилятор и так далее) на исходники могут и вовсе не смотреть, если найден готовый файл с кодом для этого модуля (как уже сказано, это желаемое поведение в большинстве случаев). За всё это приходится платить усложнением конфигураций и непонятными ошибками, которые возникают, когда неактуальные версии старых модулей собираются с обновлёнными (в случае несовпадения заголовков сборка сразу упадёт, и это хорошо, потому что хуже, когда код молча собирается и делает вовсе не то, что ожидается). Также возникают вопросы параллелизации сборки и построения её порядка. В развесистых проектах, на нескольких языках и прочем, заданию того, куда правильно нужно пнуть при обновлении такого-то исходника, модуля, интерфейса, файла данных и так далее, чтобы всё собралось, посвящены километры конфигурационных файлов.
В современных языках и системах сборки можно просто задать соответствие между артефактом abcd... и артефактом 6789..., и тогда, например, скачивание отличающейся версии какого-то кода из репозитория однозначно запустит цепочку изменений. В наследии полувековой давности за корректность отвечает функция системы сборки clean (иногда в нескольких вариантах). Да, то самое заклинание make clean. Эта конфигурация удаляет все временные (сгенерированные компилятором) файлы и заставляет пересобрать код, перегенерировать ресурсы, если нужно, и так далее. В древних системах файлики для удаления перечисляли авторы, потом системы стали помогать автоматизировать эту функцию, распихивая всё по отдельным каталогам. Если код логично разбит на модули (например, библиотеки и программа, их использующая, хотя и она может состоять из множества модулей), так можно очистить и пересобрать только нужные, не тратя время на остальные. И наоборот, в некоторых проектах висят огромные предупреждения, что на частичную сборку после частичных изменений их конфигурация не рассчитана, и сообщения об ошибках от людей, не запустивших make clean перед сборкой для обновления всего-всего, никем рассматриваться не будут.
Ты совершенно зря лезешь в какие-то подпапки и руками что-то достаёшь из репозитория. Система автоматизированная, это должно происходить само. Если не происходит, то либо авторы что-то неправильно делают, либо ты. Вероятно, даже то, что тебе что-то удалось пересобрать, является побочным эффектом. Например, какой-то кусок системы сборки обнаружил, что файлы теперь принадлежат текущему пользователю, и даты изменил при переприсвоении, что-нибудь в этом духе.
Почитаем маны:
https://man.archlinux.org/man/PKGBUILD.5
Вроде ничего про очистку результатов компиляции.
https://man.archlinux.org/man/makepkg.8.en
А вот тут есть и --clean, и --cleanbuild. Попробуй, посмотри, что они делают.
> создайте ещё 100 пакетов
Это не пакеты. Пакет — это то, что ты получаешь в результате и можешь легко и просто установить на одну систему, сто систем, тысячу, и так далее. Возможно, с какими-то изменениями, важными для устройств или сетей, которые ты администрируешь. А это рецепты сборки пакетов.
Никому не запрещено подготовить единый общий пакет, который сам всё из всех репозиториев достанет, распихает, соберёт и получит результат (очевидно, стабильную версию так и получают). Однако перечисленные тобой модули просто повторяют устройство репозиториев в проекте, и используются, скорее всего, людьми, уже знакомыми с тем, что и как от чего зависит, что совместимо, и как должно быть собрано. Эта информация у них в голове, а AUR просто помогает готовыми командами получить свежую сборку. Если же делать общий пакет, то автору придётся пристально следить за развитием кода, выбирать заведомо рабочие и совместимые коммиты, сидеть в чатике разработчиков и реагировать на сообщения «я тут попробую ошибку решить, но может начать падать на всех прочих версиях OpenGL», чтобы не собирать заведомо нерабочую программу. Понятно, что тут дохрена работы, и если кто-то из разработчиков сам не отмечает рабочие тестовые конфигурации, то рабочая работа работает работу маловероятно, что кто-то из волонтёров пожелает сидеть и каждый день заниматься только этим. Один из вариантов решения — автоматические сборки без гарантий, «если сегодняшняя тестовая версия падает — не повезло, возьмите вчерашнюю». Другой вариант — требование вести разработку и тестирование в отдельных ветках, чтобы основной репозиторий всегда содержал корректную версию кода. Если нет ни того, ни другого, то проект предлагает внешним пользователям только стабильные версии, и обо всём остальном не нужно делать никаких предположений (или не предлагает вообще никаких, как ffmpeg когда-то, в результате чего люди решили, что этот пиздец продолжаться не может, и сделали форк). Вот какая жизненно необходимая функция появилась в neovim в последние месяцы, что тебе срочно понадобилось собрать самое свеженькое? Если ты думаешь, что ща модно рэп, йоу, и все крутые пацаны в интернете делают это просто так, без особой нужды, то ты жертва моды. Если ты следишь за разработкой и хочешь посмотреть на новые возможности или исправления ошибок, то ты, по факту, внештатный тестер. Молодец, но тогда надо лучше понимать, как обращаться с нестабильными версиями.
>>8908
Все ебланы, все.
Ты хочешь пользваться штукой, не рассчитанной на простых пользователей, не понимая, что она делает, вбиваешь какие-то команды, о которых нигде не написано, вместо того, чтобы разобраться.
git не является каким-то волшебным автоматическим обновлятором всего. Когда ты вызываешь команду в каталоге с PKGBUILD, тебе копируется содержимое того же репозитория, что и при инициализации, то есть вот эти файлы:
https://aur.archlinux.org/cgit/aur.git/tree/?h=neovim-git
Больше ничего не происходит. С тем же успехом можно просто скачать какой-то архивчик с условного moipaketi.narod.ru и получить исходники и скрипты сборки (четверть века назад так программы и распространяли), но система контроля версий позволяет удобно контролировать и описывать изменения и авторам, и пользователям. Дальше makepkg запускает функции в скрипте.
Посмотрим на него:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=neovim-git
Ничего интеллектуального с версиями и датами он не делает, просто указывает источником исходников https://github.com/neovim/neovim.git и копирует добавленную автором конфигурацию запуска nvimdoc. Следовательно, оно скачивается, копируется во временную папку, собирается.
Отметим надёжную как швейцарские часы процедуру склеивания версии из циферок в cmakelists.txt. Никто не говорит, что так нельзя делать. Однако же, никто не говорит, что так можно и нужно делать. Такой цирк с конями всегда начинается, когда людям предлагается обойтись автоматизацией на bash. Можно полюбоваться на решения в
https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
Казалось бы, люди, взглянувшие на это, должны понять: «Мы все занимаемся какой-то хуйнёй».
Отметим, что AUR в базе данных хранит версию на момент загрузки PKGBUILD и не может показать актуальную, так как был предназначен для рецептов сборки конкретных версий конкретных приложений, а не произвольного кода из «будущего». Также нельзя проверить неизменность постоянно меняющихся файлов, поэтому в хэшах указан SKIP. Понятно, что предполагается, что «Github всегда безопасен», но это уже отдельная тема, которая далеко уведёт, поэтому допустим, что человек, которому понадобился свежий neovim из репозитория на Github, в любом случае доверяет Github, даже если всё проделывает руками.
Следовательно, cmake собирает приложение по представленной в исходниках конфигурации, файлы на выходе пихаются в пакет с нужным названием и метаданными.
Теперь поговорим о самой сборке. Традиционно компиляторы на C не пересобирают объектные модули, которые уже собраны, если для этого нет причин. Понятно, что если сборка библиотек в зависимостях занимает десять минут (или часов), а в программе поменялась одна строчка, хочется, чтобы пересобран был только код программы, чтобы быть заново связанным с готовым всем прочим. Причинами могут являться расхождение между штампом времени в исходниках и с скомпилированной версии или расхождение между новыми и старыми определениями связываемых функций. В зависимости от режима работы, компилятора, системы сборки (бегающей вокруг, проверяющей файлы и тыкающей им во время изменения, тыкающей в компилятор и так далее) на исходники могут и вовсе не смотреть, если найден готовый файл с кодом для этого модуля (как уже сказано, это желаемое поведение в большинстве случаев). За всё это приходится платить усложнением конфигураций и непонятными ошибками, которые возникают, когда неактуальные версии старых модулей собираются с обновлёнными (в случае несовпадения заголовков сборка сразу упадёт, и это хорошо, потому что хуже, когда код молча собирается и делает вовсе не то, что ожидается). Также возникают вопросы параллелизации сборки и построения её порядка. В развесистых проектах, на нескольких языках и прочем, заданию того, куда правильно нужно пнуть при обновлении такого-то исходника, модуля, интерфейса, файла данных и так далее, чтобы всё собралось, посвящены километры конфигурационных файлов.
В современных языках и системах сборки можно просто задать соответствие между артефактом abcd... и артефактом 6789..., и тогда, например, скачивание отличающейся версии какого-то кода из репозитория однозначно запустит цепочку изменений. В наследии полувековой давности за корректность отвечает функция системы сборки clean (иногда в нескольких вариантах). Да, то самое заклинание make clean. Эта конфигурация удаляет все временные (сгенерированные компилятором) файлы и заставляет пересобрать код, перегенерировать ресурсы, если нужно, и так далее. В древних системах файлики для удаления перечисляли авторы, потом системы стали помогать автоматизировать эту функцию, распихивая всё по отдельным каталогам. Если код логично разбит на модули (например, библиотеки и программа, их использующая, хотя и она может состоять из множества модулей), так можно очистить и пересобрать только нужные, не тратя время на остальные. И наоборот, в некоторых проектах висят огромные предупреждения, что на частичную сборку после частичных изменений их конфигурация не рассчитана, и сообщения об ошибках от людей, не запустивших make clean перед сборкой для обновления всего-всего, никем рассматриваться не будут.
Ты совершенно зря лезешь в какие-то подпапки и руками что-то достаёшь из репозитория. Система автоматизированная, это должно происходить само. Если не происходит, то либо авторы что-то неправильно делают, либо ты. Вероятно, даже то, что тебе что-то удалось пересобрать, является побочным эффектом. Например, какой-то кусок системы сборки обнаружил, что файлы теперь принадлежат текущему пользователю, и даты изменил при переприсвоении, что-нибудь в этом духе.
Почитаем маны:
https://man.archlinux.org/man/PKGBUILD.5
Вроде ничего про очистку результатов компиляции.
https://man.archlinux.org/man/makepkg.8.en
А вот тут есть и --clean, и --cleanbuild. Попробуй, посмотри, что они делают.
Это не пакеты. Пакет — это то, что ты получаешь в результате и можешь легко и просто установить на одну систему, сто систем, тысячу, и так далее. Возможно, с какими-то изменениями, важными для устройств или сетей, которые ты администрируешь. А это рецепты сборки пакетов.
Никому не запрещено подготовить единый общий пакет, который сам всё из всех репозиториев достанет, распихает, соберёт и получит результат (очевидно, стабильную версию так и получают). Однако перечисленные тобой модули просто повторяют устройство репозиториев в проекте, и используются, скорее всего, людьми, уже знакомыми с тем, что и как от чего зависит, что совместимо, и как должно быть собрано. Эта информация у них в голове, а AUR просто помогает готовыми командами получить свежую сборку. Если же делать общий пакет, то автору придётся пристально следить за развитием кода, выбирать заведомо рабочие и совместимые коммиты, сидеть в чатике разработчиков и реагировать на сообщения «я тут попробую ошибку решить, но может начать падать на всех прочих версиях OpenGL», чтобы не собирать заведомо нерабочую программу. Понятно, что тут дохрена работы, и если кто-то из разработчиков сам не отмечает рабочие тестовые конфигурации, то рабочая работа работает работу маловероятно, что кто-то из волонтёров пожелает сидеть и каждый день заниматься только этим. Один из вариантов решения — автоматические сборки без гарантий, «если сегодняшняя тестовая версия падает — не повезло, возьмите вчерашнюю». Другой вариант — требование вести разработку и тестирование в отдельных ветках, чтобы основной репозиторий всегда содержал корректную версию кода. Если нет ни того, ни другого, то проект предлагает внешним пользователям только стабильные версии, и обо всём остальном не нужно делать никаких предположений (или не предлагает вообще никаких, как ffmpeg когда-то, в результате чего люди решили, что этот пиздец продолжаться не может, и сделали форк). Вот какая жизненно необходимая функция появилась в neovim в последние месяцы, что тебе срочно понадобилось собрать самое свеженькое? Если ты думаешь, что ща модно рэп, йоу, и все крутые пацаны в интернете делают это просто так, без особой нужды, то ты жертва моды. Если ты следишь за разработкой и хочешь посмотреть на новые возможности или исправления ошибок, то ты, по факту, внештатный тестер. Молодец, но тогда надо лучше понимать, как обращаться с нестабильными версиями.
Все ебланы, все.
Ты хочешь пользваться штукой, не рассчитанной на простых пользователей, не понимая, что она делает, вбиваешь какие-то команды, о которых нигде не написано, вместо того, чтобы разобраться.
git не является каким-то волшебным автоматическим обновлятором всего. Когда ты вызываешь команду в каталоге с PKGBUILD, тебе копируется содержимое того же репозитория, что и при инициализации, то есть вот эти файлы:
https://aur.archlinux.org/cgit/aur.git/tree/?h=neovim-git
Больше ничего не происходит. С тем же успехом можно просто скачать какой-то архивчик с условного moipaketi.narod.ru и получить исходники и скрипты сборки (четверть века назад так программы и распространяли), но система контроля версий позволяет удобно контролировать и описывать изменения и авторам, и пользователям. Дальше makepkg запускает функции в скрипте.
Посмотрим на него:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=neovim-git
Ничего интеллектуального с версиями и датами он не делает, просто указывает источником исходников https://github.com/neovim/neovim.git и копирует добавленную автором конфигурацию запуска nvimdoc. Следовательно, оно скачивается, копируется во временную папку, собирается.
Отметим надёжную как швейцарские часы процедуру склеивания версии из циферок в cmakelists.txt. Никто не говорит, что так нельзя делать. Однако же, никто не говорит, что так можно и нужно делать. Такой цирк с конями всегда начинается, когда людям предлагается обойтись автоматизацией на bash. Можно полюбоваться на решения в
https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
Казалось бы, люди, взглянувшие на это, должны понять: «Мы все занимаемся какой-то хуйнёй».
Отметим, что AUR в базе данных хранит версию на момент загрузки PKGBUILD и не может показать актуальную, так как был предназначен для рецептов сборки конкретных версий конкретных приложений, а не произвольного кода из «будущего». Также нельзя проверить неизменность постоянно меняющихся файлов, поэтому в хэшах указан SKIP. Понятно, что предполагается, что «Github всегда безопасен», но это уже отдельная тема, которая далеко уведёт, поэтому допустим, что человек, которому понадобился свежий neovim из репозитория на Github, в любом случае доверяет Github, даже если всё проделывает руками.
Следовательно, cmake собирает приложение по представленной в исходниках конфигурации, файлы на выходе пихаются в пакет с нужным названием и метаданными.
Теперь поговорим о самой сборке. Традиционно компиляторы на C не пересобирают объектные модули, которые уже собраны, если для этого нет причин. Понятно, что если сборка библиотек в зависимостях занимает десять минут (или часов), а в программе поменялась одна строчка, хочется, чтобы пересобран был только код программы, чтобы быть заново связанным с готовым всем прочим. Причинами могут являться расхождение между штампом времени в исходниках и с скомпилированной версии или расхождение между новыми и старыми определениями связываемых функций. В зависимости от режима работы, компилятора, системы сборки (бегающей вокруг, проверяющей файлы и тыкающей им во время изменения, тыкающей в компилятор и так далее) на исходники могут и вовсе не смотреть, если найден готовый файл с кодом для этого модуля (как уже сказано, это желаемое поведение в большинстве случаев). За всё это приходится платить усложнением конфигураций и непонятными ошибками, которые возникают, когда неактуальные версии старых модулей собираются с обновлёнными (в случае несовпадения заголовков сборка сразу упадёт, и это хорошо, потому что хуже, когда код молча собирается и делает вовсе не то, что ожидается). Также возникают вопросы параллелизации сборки и построения её порядка. В развесистых проектах, на нескольких языках и прочем, заданию того, куда правильно нужно пнуть при обновлении такого-то исходника, модуля, интерфейса, файла данных и так далее, чтобы всё собралось, посвящены километры конфигурационных файлов.
В современных языках и системах сборки можно просто задать соответствие между артефактом abcd... и артефактом 6789..., и тогда, например, скачивание отличающейся версии какого-то кода из репозитория однозначно запустит цепочку изменений. В наследии полувековой давности за корректность отвечает функция системы сборки clean (иногда в нескольких вариантах). Да, то самое заклинание make clean. Эта конфигурация удаляет все временные (сгенерированные компилятором) файлы и заставляет пересобрать код, перегенерировать ресурсы, если нужно, и так далее. В древних системах файлики для удаления перечисляли авторы, потом системы стали помогать автоматизировать эту функцию, распихивая всё по отдельным каталогам. Если код логично разбит на модули (например, библиотеки и программа, их использующая, хотя и она может состоять из множества модулей), так можно очистить и пересобрать только нужные, не тратя время на остальные. И наоборот, в некоторых проектах висят огромные предупреждения, что на частичную сборку после частичных изменений их конфигурация не рассчитана, и сообщения об ошибках от людей, не запустивших make clean перед сборкой для обновления всего-всего, никем рассматриваться не будут.
Ты совершенно зря лезешь в какие-то подпапки и руками что-то достаёшь из репозитория. Система автоматизированная, это должно происходить само. Если не происходит, то либо авторы что-то неправильно делают, либо ты. Вероятно, даже то, что тебе что-то удалось пересобрать, является побочным эффектом. Например, какой-то кусок системы сборки обнаружил, что файлы теперь принадлежат текущему пользователю, и даты изменил при переприсвоении, что-нибудь в этом духе.
Почитаем маны:
https://man.archlinux.org/man/PKGBUILD.5
Вроде ничего про очистку результатов компиляции.
https://man.archlinux.org/man/makepkg.8.en
А вот тут есть и --clean, и --cleanbuild. Попробуй, посмотри, что они делают.
> создайте ещё 100 пакетов
Это не пакеты. Пакет — это то, что ты получаешь в результате и можешь легко и просто установить на одну систему, сто систем, тысячу, и так далее. Возможно, с какими-то изменениями, важными для устройств или сетей, которые ты администрируешь. А это рецепты сборки пакетов.
Никому не запрещено подготовить единый общий пакет, который сам всё из всех репозиториев достанет, распихает, соберёт и получит результат (очевидно, стабильную версию так и получают). Однако перечисленные тобой модули просто повторяют устройство репозиториев в проекте, и используются, скорее всего, людьми, уже знакомыми с тем, что и как от чего зависит, что совместимо, и как должно быть собрано. Эта информация у них в голове, а AUR просто помогает готовыми командами получить свежую сборку. Если же делать общий пакет, то автору придётся пристально следить за развитием кода, выбирать заведомо рабочие и совместимые коммиты, сидеть в чатике разработчиков и реагировать на сообщения «я тут попробую ошибку решить, но может начать падать на всех прочих версиях OpenGL», чтобы не собирать заведомо нерабочую программу. Понятно, что тут дохрена работы, и если кто-то из разработчиков сам не отмечает рабочие тестовые конфигурации, то рабочая работа работает работу маловероятно, что кто-то из волонтёров пожелает сидеть и каждый день заниматься только этим. Один из вариантов решения — автоматические сборки без гарантий, «если сегодняшняя тестовая версия падает — не повезло, возьмите вчерашнюю». Другой вариант — требование вести разработку и тестирование в отдельных ветках, чтобы основной репозиторий всегда содержал корректную версию кода. Если нет ни того, ни другого, то проект предлагает внешним пользователям только стабильные версии, и обо всём остальном не нужно делать никаких предположений (или не предлагает вообще никаких, как ffmpeg когда-то, в результате чего люди решили, что этот пиздец продолжаться не может, и сделали форк). Вот какая жизненно необходимая функция появилась в neovim в последние месяцы, что тебе срочно понадобилось собрать самое свеженькое? Если ты думаешь, что ща модно рэп, йоу, и все крутые пацаны в интернете делают это просто так, без особой нужды, то ты жертва моды. Если ты следишь за разработкой и хочешь посмотреть на новые возможности или исправления ошибок, то ты, по факту, внештатный тестер. Молодец, но тогда надо лучше понимать, как обращаться с нестабильными версиями.
>>9114
Всё ясно: ты — читатель газет, существующий в том же самом манямирке, состоящем из current things.
> каждую секунду у него в компьютере выполняется код тысяч пузатых волосатых немытых программистов, попёрдывающих в кресла и, к примеру, дрочащих на мальчиков, раздвигающих попку перед огромным членом
> все такие картинки он игнорирует и думает только о тех, про которые ему было сказано думать в медиа
Всё ясно: ты — читатель газет, существующий в том же самом манямирке, состоящем из current things.
>>9126
Странноватый перевод.
Блин, я этот пост после выхода читал, и точно на Hacker News, но там ноль обсуждений, тогда как?!
https://ploum.net/2024-10-20-20years-linux-desktop-part1.html
https://ploum.net/2024-12-16-linux_desktop2.html
А, понятно, из истории видно, что случайно попалась ссылка на блог, а там как раз этот пост висел.
Странноватый перевод.
Блин, я этот пост после выхода читал, и точно на Hacker News, но там ноль обсуждений, тогда как?!
https://ploum.net/2024-10-20-20years-linux-desktop-part1.html
https://ploum.net/2024-12-16-linux_desktop2.html
А, понятно, из истории видно, что случайно попалась ссылка на блог, а там как раз этот пост висел.
>>9134
я газет не читаю, а вот то что чубатые палестинцы уже форматировали диски из-за локали и айпишника знаю непонаслышке. на что там дрочат программисты мне похуй, это личное дело, а вот когда программист приносит политику (особенно максимально лицемерную уровня "израилю можно - вам нельзя, папа финский коммунист работавший на деньги кремля - сынок борец с рашн агрешн") на рабочее место это уже не программист а политрук, и политруков надо избегать при любой возможности.
я газет не читаю, а вот то что чубатые палестинцы уже форматировали диски из-за локали и айпишника знаю непонаслышке. на что там дрочат программисты мне похуй, это личное дело, а вот когда программист приносит политику (особенно максимально лицемерную уровня "израилю можно - вам нельзя, папа финский коммунист работавший на деньги кремля - сынок борец с рашн агрешн") на рабочее место это уже не программист а политрук, и политруков надо избегать при любой возможности.
>>9142
https://w.wiki/CVKP
Как пел Петросян, «я вообще никогда не читаю».
Если у тебя произвольная программа форматирует диск, это значит только то, что ты не контролируешь, что происходит на твоём компьютере, и просто надеешься на авось. Твои рассуждения о том, как «положено» работать, на это не влияют, и являются всего лишь выдачей желаемого за действительное.
> я газет не читаю
https://w.wiki/CVKP
Как пел Петросян, «я вообще никогда не читаю».
Если у тебя произвольная программа форматирует диск, это значит только то, что ты не контролируешь, что происходит на твоём компьютере, и просто надеешься на авось. Твои рассуждения о том, как «положено» работать, на это не влияют, и являются всего лишь выдачей желаемого за действительное.
>>8848
slax
slax
>>9126
И уже больше десяти как не готов, так как перешли от пик1 до пик2.
И уже больше десяти как не готов, так как перешли от пик1 до пик2.
>>9160
Ну если дох времени, то поковырятся ещё можно, у меня openbox в ubuntu на старте 150mib жрёт, сижу с хромом на 4 гектарах, но челу сверху с одним ничего не светит.
Ну если дох времени, то поковырятся ещё можно, у меня openbox в ubuntu на старте 150mib жрёт, сижу с хромом на 4 гектарах, но челу сверху с одним ничего не светит.
>>9158
Пофиксил. У меня гента и сегодня меньше 300 МБ ест.
>современный убунту это неоптимизированное говно
Пофиксил. У меня гента и сегодня меньше 300 МБ ест.
>>9160
Какая хуй разница, что в линупсе у тебя условно джва жижабайта в простое, что в бзде будет плюсминус так же.
Ибо проблема оптимизации швабодных и открытых ос не в ядрах, а в убогоньких GovnoToolKit'ах, парашном софте на electron и прочих высерах жалких говнокодеришек на убогоньких недотулкитах.
Какая хуй разница, что в линупсе у тебя условно джва жижабайта в простое, что в бзде будет плюсминус так же.
Ибо проблема оптимизации швабодных и открытых ос не в ядрах, а в убогоньких GovnoToolKit'ах, парашном софте на electron и прочих высерах жалких говнокодеришек на убогоньких недотулкитах.
>>9170
К чему эта экономия на спичках? Тем более, что процентов 90 памяти у тебя жрёт браузер, от которого ты не торопишься отказываться
К чему эта экономия на спичках? Тем более, что процентов 90 памяти у тебя жрёт браузер, от которого ты не торопишься отказываться
>>9177
К тому что некропекарня. Вот чтоб браузеру хватало памяти и можно было комфортно работать, и нужна эта экономия.\
А так-то да, все эти раздутые линупсы рассчитаны на современные сетапы, где не жалко лишнего гигабайта-двух ради красивого интерфейса со свистелками и перделками. С тем же эффектом можно еще вспомнить досовские времена, когда память измерялась в мегабайтах, а стандартным носителем была дискета на 1.44 мб.
К тому что некропекарня. Вот чтоб браузеру хватало памяти и можно было комфортно работать, и нужна эта экономия.\
А так-то да, все эти раздутые линупсы рассчитаны на современные сетапы, где не жалко лишнего гигабайта-двух ради красивого интерфейса со свистелками и перделками. С тем же эффектом можно еще вспомнить досовские времена, когда память измерялась в мегабайтах, а стандартным носителем была дискета на 1.44 мб.
>>9182
Комфортно? На некропекарне? Не смеши.
Сдай свой хлам какому-нибудь лоху на авито и купи одноплатник на n100 за 9к.
Браузер, при его-то аппетитах, твою сотню-две-три сэкономленных мегабайт даже не заметит.
>некропекарня
>Вот чтоб браузеру хватало памяти и можно было комфортно работать
Комфортно? На некропекарне? Не смеши.
Сдай свой хлам какому-нибудь лоху на авито и купи одноплатник на n100 за 9к.
>нужна эта экономия.
Браузер, при его-то аппетитах, твою сотню-две-три сэкономленных мегабайт даже не заметит.
>>9189
Представь себе, да.
А вот сэкономленный гигабайт-другой очень даже чувствует.
>Комфортно? На некропекарне?
Представь себе, да.
>твою сотню-две-три сэкономленных мегабайт даже не заметит
А вот сэкономленный гигабайт-другой очень даже чувствует.
>>9191
Как раз-то представить я себе могу, сам такой хуйнёй занимался.
Да, привыкнуть можно, но зачем? Тем более, когда есть одноплатники, доступные любому нищеброду. С адекватным объемом оперативы и по производительности на уровне i5 7k.
>Представь себе, да.
Как раз-то представить я себе могу, сам такой хуйнёй занимался.
Да, привыкнуть можно, но зачем? Тем более, когда есть одноплатники, доступные любому нищеброду. С адекватным объемом оперативы и по производительности на уровне i5 7k.
>>9200
Даже gentoo втянула в себя systemd. Пока что опционально, но чую со временем openrc ждёт стагнация.
Даже gentoo втянула в себя systemd. Пока что опционально, но чую со временем openrc ждёт стагнация.
>>9175
С ними пкм хрома без ебучего скролла, кстати очень приятный шрифт, а не это говно вроде liberation
С ними пкм хрома без ебучего скролла, кстати очень приятный шрифт, а не это говно вроде liberation
>>9201
Он уже давно не развивается, его только поддерживают. С другой стороны, это и не системд, который пытается поглотить всё больше и больше компонентов.
>>9200
Какие "стандартные утилиты"? Coreutils и util-linux в том же составе, что и 20лет назад.
Экосистема развивается - да, действительно. Но это нормально для живой системы.
>но чую со временем openrc ждёт стагнация
Он уже давно не развивается, его только поддерживают. С другой стороны, это и не системд, который пытается поглотить всё больше и больше компонентов.
>>9200
>В линупсе стандартные утилиты часто меняются, в бсд нет.
Какие "стандартные утилиты"? Coreutils и util-linux в том же составе, что и 20лет назад.
Экосистема развивается - да, действительно. Но это нормально для живой системы.
>>9203
Пиздец, хромопроблемы.
Максимально колхозанский. Что-то на уровне комиксанса
>С ними пкм хрома без ебучего скролла
Пиздец, хромопроблемы.
>кстати очень приятный шрифт
Максимально колхозанский. Что-то на уровне комиксанса
>>9206
Alsa, pulse, pipewire...
Iptables, nftables...
Networkmanager, netplan...
Ifconfig, ip...
Забрасывают одно, выкатывают нестабильное новое говно. Еле дотягивают до стабильной версии, затем переписывают на новом модном язычке. Снова переписывают и так по кругу. Круговорот недоделанного говна. Это не развитие, а распил бюджета крупных корпораций.
> Какие "стандартные утилиты"?
Alsa, pulse, pipewire...
Iptables, nftables...
Networkmanager, netplan...
Ifconfig, ip...
> Экосистема развивается - да, действительно. Но это нормально для живой системы.
Забрасывают одно, выкатывают нестабильное новое говно. Еле дотягивают до стабильной версии, затем переписывают на новом модном язычке. Снова переписывают и так по кругу. Круговорот недоделанного говна. Это не развитие, а распил бюджета крупных корпораций.
>>9206
Наткнулся недавно на пост, мол разраб galculator (калькулятор) его забросил, срочно нужно форкнуть и развивать. Ну ты понял, что я хотел сказать.
> его только поддерживают
Наткнулся недавно на пост, мол разраб galculator (калькулятор) его забросил, срочно нужно форкнуть и развивать. Ну ты понял, что я хотел сказать.
>>9208
Хром поддерживает все шрифты, мразилла ж хуй, шрифт Andika, колхозанский, так колхозанский.
Хром поддерживает все шрифты, мразилла ж хуй, шрифт Andika, колхозанский, так колхозанский.
>>9209
Это не "стандартные утилиты", а компоненты экосистемы.
При том то, что ты перечислил, - качественно сильно разные вещи. Особенно альса, пульса и пайпваир: звуковая подсистема, звуковой сервер и полноценная мультимедийная система.
В бсд таких изменений нет, потому что их экосистема давно стагнирует. Там до сих пор аналогом альсы обходятся.
Это не "стандартные утилиты", а компоненты экосистемы.
При том то, что ты перечислил, - качественно сильно разные вещи. Особенно альса, пульса и пайпваир: звуковая подсистема, звуковой сервер и полноценная мультимедийная система.
В бсд таких изменений нет, потому что их экосистема давно стагнирует. Там до сих пор аналогом альсы обходятся.
>>9216
Получается ты прав. Тогда наверну devops практик, непрерывную интеграцию, а дидов пошлю нафиг. Тормозят прогресс, внушают молодёжи копролиты.
Получается ты прав. Тогда наверну devops практик, непрерывную интеграцию, а дидов пошлю нафиг. Тормозят прогресс, внушают молодёжи копролиты.
>>9206
Заебись же, унифицированный, пиздато задокументированный фреймворк, модули которого заменяют кучу легаси параши из 80х, разные говнокроны, башпортянки всратые и прочие костыли на дедовском говнокоде, логи блять в одном месте лежат, красота ж нахуй.
>который пытается поглотить всё больше и больше компонентов
Заебись же, унифицированный, пиздато задокументированный фреймворк, модули которого заменяют кучу легаси параши из 80х, разные говнокроны, башпортянки всратые и прочие костыли на дедовском говнокоде, логи блять в одном месте лежат, красота ж нахуй.
>>9232
Модули, фреймворк, унификация... а ты точно про системд говоришь? Про эту забагованная куча говна, куда навалили всего, до чего руки дотянулись? Да такого размера куча, что её только могила исправит. Либо сверхмощный небыдлокодерский ИИ, если такой появится раньше.
Кстати, я тут недавно alpine настраивал на встраиваемой системе. OpenRC был прямо таки глотком свежего воздуха. Я уже и забыл, что система инициализации может быть простой и прозрачной, и просто работать.
>Заебись же, унифицированный, пиздато задокументированный фреймворк, модули которого заменяют кучу легаси параши из 80х
Модули, фреймворк, унификация... а ты точно про системд говоришь? Про эту забагованная куча говна, куда навалили всего, до чего руки дотянулись? Да такого размера куча, что её только могила исправит. Либо сверхмощный небыдлокодерский ИИ, если такой появится раньше.
Кстати, я тут недавно alpine настраивал на встраиваемой системе. OpenRC был прямо таки глотком свежего воздуха. Я уже и забыл, что система инициализации может быть простой и прозрачной, и просто работать.
>>9243
Ты меня просто ошарашил. Настолько невпопад и настолько жиденько, что даже не знаю, чем и против чего тут можно возразить. Какие деды, какие практики, причём тут CI, что ты им противопоставляешь и каким боком тут стандартные утилиты? Ударим седом по докеру или чо?
Ты меня просто ошарашил. Настолько невпопад и настолько жиденько, что даже не знаю, чем и против чего тут можно возразить. Какие деды, какие практики, причём тут CI, что ты им противопоставляешь и каким боком тут стандартные утилиты? Ударим седом по докеру или чо?
>>9182
Ты в курсе, что ты можешь на лохито взять набор мать+проц неплохой серверный + 16гигов озу за 7к? Либо на али. Остальное со старого компа переставишь и не будешь мучаться. Даже школьник может 7к накопить
Ты в курсе, что ты можешь на лохито взять набор мать+проц неплохой серверный + 16гигов озу за 7к? Либо на али. Остальное со старого компа переставишь и не будешь мучаться. Даже школьник может 7к накопить
23 Кб, 798x187>>9269
СОСАТЬ!
СОСАТЬ!
>>9244
Лол, а я как раз наоборот. После трех с лишним лет на генте я решил пощупать другие дистры(на другом разделе, разумеется), и в дебиане решил подразобраться с системд. Я немного подохуел с того как там все нахуеверчено, все в кучу, и сервисы, и монтирование, и сеть, и еще чего-то. Все это выглядит совершенно громоздко и нелогично по сравнению с тем, когда разные функции делегируются разным утилитам.
>OpenRC был прямо таки глотком свежего воздуха. Я уже и забыл, что система инициализации может быть простой и прозрачной, и просто работать
Лол, а я как раз наоборот. После трех с лишним лет на генте я решил пощупать другие дистры(на другом разделе, разумеется), и в дебиане решил подразобраться с системд. Я немного подохуел с того как там все нахуеверчено, все в кучу, и сервисы, и монтирование, и сеть, и еще чего-то. Все это выглядит совершенно громоздко и нелогично по сравнению с тем, когда разные функции делегируются разным утилитам.
>>9275
Ничего там не свалено в кучу. Удали "systemd" из названия демонов и получишь те отдельные утилиты. Timesyncd, resolved и тд. Это психологически воспринимается монолитом. На деле сервисы отдельные.
Ничего там не свалено в кучу. Удали "systemd" из названия демонов и получишь те отдельные утилиты. Timesyncd, resolved и тд. Это психологически воспринимается монолитом. На деле сервисы отдельные.
Расходы Linux LGBT Foundation на ядро - 6.8 млн. долларов
Расходы Linux LGBT Foundation на пролапс - 292,89 млн. долларов
Организация заработала 292.2 млн. долларов, а израсходовала 299.7 млн долларов
В принципе это всё, что нужно знать, думайТЕ.
https://www.opennet.ru/opennews/art.shtml?num=62456
Расходы Linux LGBT Foundation на пролапс - 292,89 млн. долларов
Организация заработала 292.2 млн. долларов, а израсходовала 299.7 млн долларов
В принципе это всё, что нужно знать, думайТЕ.
https://www.opennet.ru/opennews/art.shtml?num=62456
>>9269
Так у меня полноценная ubuntu, а не 32 битный старый паппи с флешки, который ты загрузил на 5 минут.
Так у меня полноценная ubuntu, а не 32 битный старый паппи с флешки, который ты загрузил на 5 минут.
>>9298
Так я и соответствую, раз пользуюсь этим говном.
Так я и соответствую, раз пользуюсь этим говном.
>>9300
У меня полноценная 64х гента, а не то что ты подумал.
У меня полноценная 64х гента, а не то что ты подумал.
>>9294
Уже обсуждали. Помимо ядра есть дохуя проектов на лине, вроде контейнеров и виртуализации, за которые компании готовы много платить
Уже обсуждали. Помимо ядра есть дохуя проектов на лине, вроде контейнеров и виртуализации, за которые компании готовы много платить
>>9338
Расходы на поддержание инфраструктуры почти не изменились и составили $22.69 млн (7.6%, год назад - $22.58);
Расходы на не связанные с ядром проекты увеличились с $171.8 до $193.7 млн (64.6%);
Затраты на программы обучения и сертификации выросли с $18.57 млн до $23.1 млн. (7.7%);
Затраты на корпоративные операции выросли c $17.1 млн до $18.9 млн (6.3%);
Расходы на проведение мероприятий выросли с $14.6 млн до $15.2 млн (5%);
Затраты на сопровождение сообщества почти не изменились и составили $13.7 млн (4.5%, год назад - $13.5 млн);
Расходы на международные операции выросли с $2.96 млн до $5.6 млн (1.8%).
Где здесь про контейнеры, просто иди нахуй пидор.
Расходы на поддержание инфраструктуры почти не изменились и составили $22.69 млн (7.6%, год назад - $22.58);
Расходы на не связанные с ядром проекты увеличились с $171.8 до $193.7 млн (64.6%);
Затраты на программы обучения и сертификации выросли с $18.57 млн до $23.1 млн. (7.7%);
Затраты на корпоративные операции выросли c $17.1 млн до $18.9 млн (6.3%);
Расходы на проведение мероприятий выросли с $14.6 млн до $15.2 млн (5%);
Затраты на сопровождение сообщества почти не изменились и составили $13.7 млн (4.5%, год назад - $13.5 млн);
Расходы на международные операции выросли с $2.96 млн до $5.6 млн (1.8%).
Где здесь про контейнеры, просто иди нахуй пидор.
>>9340
Им донатят в том числе на проекты связанные с ядром. Или ты думаешь, корпы миллионы донатят и забивают хуй на потраченные деньги? Там выебут всех, если деньги потратят не на то, куда их спонсоры выделили
Им донатят в том числе на проекты связанные с ядром. Или ты думаешь, корпы миллионы донатят и забивают хуй на потраченные деньги? Там выебут всех, если деньги потратят не на то, куда их спонсоры выделили
>>9342
Штольман поссал тебе в рот, не отвлекай меня левак.
Штольман поссал тебе в рот, не отвлекай меня левак.
>>9341
Ты просто тупорылая хуйня с 1.5 извилинами, которая дальше заголовка с опеннета читать не умеет, а уже имеет чсв до небес и посылает всех нахуй
https://linuxfoundation.eu/en/projects
Просвещайся, чмо
Ты просто тупорылая хуйня с 1.5 извилинами, которая дальше заголовка с опеннета читать не умеет, а уже имеет чсв до небес и посылает всех нахуй
https://linuxfoundation.eu/en/projects
Просвещайся, чмо
67 Кб, 1341x317>>9340
Ага, школьники и студенты перечисляют по 100 рублей.
Пикрелейтед партнёры решат без тебя куда деньги пускать, а на анальников хватит и 7 миллионов в год.
> деньги донатят
Ага, школьники и студенты перечисляют по 100 рублей.
Пикрелейтед партнёры решат без тебя куда деньги пускать, а на анальников хватит и 7 миллионов в год.
>>9336
Тот, в котором по 750 тысяч строк изменений каждый релиз. Возможно, слышал про такой? Linux называется.
>Какой блядь проект
Тот, в котором по 750 тысяч строк изменений каждый релиз. Возможно, слышал про такой? Linux называется.
Господи, какая же ебля у убунты чтобы заставить звук работать. В прошлых версиях pulseaudio, к 22 завезли pipewire и я весь год ахуевал, почему звук глючит и постоянно перестаёт работать если быстро включать и выключать (конфликт был). Удалил pulseaudio и все норм стало.
Нет, другие дистрибутивы не буду ставить, у меня ноутбук с очень экзотической картой, в убунте из коробки это пришло. не буду дистрохоппингом заниматься. Что смешно, звуковая карта в ноуте по советам с двача из официального треда.
Нет, другие дистрибутивы не буду ставить, у меня ноутбук с очень экзотической картой, в убунте из коробки это пришло. не буду дистрохоппингом заниматься. Что смешно, звуковая карта в ноуте по советам с двача из официального треда.
>>9366
Удалить пульсу и ту новую хуйню, поменять пару значений в /usr/share/alsa/alsa.conf всё
Удалить пульсу и ту новую хуйню, поменять пару значений в /usr/share/alsa/alsa.conf всё
>>9356
750 тысяч строк на 6.8 млн, а 300 млн пробухать, ещё раз иди нахуй штольманутый
750 тысяч строк на 6.8 млн, а 300 млн пробухать, ещё раз иди нахуй штольманутый
>>9340
Кто тебе это сказал-то? На что дают, на то и тратят. Допустим, у компании сервера, и им надо, чтобы они ещё десять лет проработали, и всё, что на них крутится — тоже. Если это критично для них, то они у себя создают отдел с людьми, которые это будут пилить и коммитить в опенсорс. Если очень богатые — даже железо собственное разрабатывают и заказывают, оптимальное под свои задачи. Если это только потребление каких-то продуктов, без особых изменений под себя, то можно задвинуть чемодан денег в фонд и сказать «нам нужно, чтобы вот это, вот это и вот это поддерживалось на долгий срок, подкиньте разработчикам на гречку и макарошки».
Кто тебе это сказал-то? На что дают, на то и тратят. Допустим, у компании сервера, и им надо, чтобы они ещё десять лет проработали, и всё, что на них крутится — тоже. Если это критично для них, то они у себя создают отдел с людьми, которые это будут пилить и коммитить в опенсорс. Если очень богатые — даже железо собственное разрабатывают и заказывают, оптимальное под свои задачи. Если это только потребление каких-то продуктов, без особых изменений под себя, то можно задвинуть чемодан денег в фонд и сказать «нам нужно, чтобы вот это, вот это и вот это поддерживалось на долгий срок, подкиньте разработчикам на гречку и макарошки».