Премини към съдържанието

borovaka

Потребител
  • Публикации

    674
  • Регистрация

  • Последно онлайн

Всичко публикувано от borovaka

  1. borovaka

    XAMP+openSuse малко помощ

    Говоря за Development машина - не мисля, че ще седнеш да пишеш нещо на HP-UX
  2. borovaka

    XAMP+openSuse малко помощ

    Аз се чудя кой все още си инсталира XAMPP/LAMP и други stack-ове, за Development. При наличието на контейнери не виждам абсолютно никакъв смисъл (освен ако не правиш експериметни с администрация на самите сървиси)
  3. borovaka

    Линукс мемета

    // offtopic Ти като го пишеш това - вярваш ли си Това в Desktop сегмента ли го гледаш? - щото картината е такава само там
  4. borovaka

    Снимки на Вашия Linux - част 2

    Като гледам имаш 16GB memory, защо се интересуваш дали е много или малко използваната памет? Реално това дето всички го гледат - колко памет заема приложение е глупост - неизползваната ти памет е waste ресурс, ако си стои. Access time - то и към паметта ти и много по-бъри, за това доста приложения - браузъри, kernel и т.н. държат ресурси там за по-бърз достъп. Това не значи, че ще ти свърши паметта (в повечето случаи), има имплементиран механизъм в приложенията, който следи заеманата памет и когато стигне до някакъв лимит се зачиства.
  5. borovaka

    Linux - обща дискусия 3

    Точно това е проблема - по този начин си създаваш security hell п.с. И тук пак мисля, че гледаш от позиция на десктоп потребител. В смисъл, това, че аз си freeze-вам някакви версии на мизерния ми лаптоп и съм happy, ако нещо се прецака, не значи, че ще го направя това на prod server. За Windows можеш да инсталираш ъпдейтите гранулярно, ако си join-ат в домейн - администратора може да избира. За Desktop Windows , си си платил точно за това - ти да не се занимаваш и те да ти update-ват software (дали ъпдейта е читав е съвсем друга тема на разговор, ама тогава можеш да им търсиш отговъорност - за това си си платил)
  6. borovaka

    Linux - обща дискусия 3

    Аз пък изобщо не съм на това мнение. Никой не му дреме особено много за вашата "телеметрия" (освен да ви ползват като free тестери - и да се отстраняват проблемите в последствие - а не предварително ). Ще сложат само online акаунти не, толкова за да ви следят инфото - колкото да ви вържат да ползвате "клауд инфраструктурата им". Те реално от това печелят. Точно в последно време Azure набира много-голяма скорост като cloud provider. Скоро пуснаха и виртуален декстоп, който директно ти stream-ва машината към thin client - с което още повече ще връзват към тяхната инфраструктура. Съответно това или ще си го заплащате, или ще си предоставяте данните - с което пак ще го плащате - безплатен обяд няма. Аз се чудя много защо толкова се хейти политиката на MS и Windows. То и във free software е същото. RH (основно) плаща на програмисти, спонсорира проекти и т.н. - от там нататък ви се хвърля software по дистротата, които са по нестабилни Arch/Fedora и т.н. - вие тествате и репортвате бъгове (каквито има страшно много) и после отсятият софтуер отива в RHEL. И никой да не ми приказва, че не били само RH ( изключвам другите корпорации разбира се - Intel/AMD/Samsung/VMWare/Citrix etc.), които реално движат всичко. На "добра воля" има много малко проекти. MS в момента правят същото - пускат няколко insider ring-a + canary release на версия на windows - виждат какво се на*ира, и решават дали да freeze-нат update. А това ,че update-ите не можело да се manege-ват - релано в RHEL примерно как ги manage-вате? - versionlock/exclude на пакети ли? - щото това е чисто security issue. Аз пък съм напълно съгласен с политиката на MS - rolling release и директно continuous delivery - изобщо не трябва да се интересуват дали Гошо/Пешо/Иван имат машини от преди 15 години, които ползват не се знае какъв хардуер и оправляват примерно водна централ или скенер - това е проблем на вендора на скенера/централата и т.н. Точно наскоро гледах някаква презентация за новия терминал който правят - и пича обясняваше как всичко е писано преди 100 години с легаси код, обаче като се опитат да го бутнат - някой пирмерно от нещо "критично" изревава ,че държи сървис писан преди 15 години, който разчита на това колко символа има напечатани в терминала. Е сори ама за такива простотии не са виновни MS а простака дето е правил софтуер за електроцентрала (перимерно) който работи по тоя начин. Та хейтите всички, ама ако вие го пишете софтуера (без значение, дали е за MS,RH или кой да е) ми и интересно как ще handle-вате нещата. А по темата за "administration hell-a", който ставал - има му лесното. Хората ви предлагат да си изнесете цялата инфраструктура при тях и те да ви manage-ват сървисите Така всички ще са доволни п.с. Малко се еб..(бъзикам) в поста за някой неща - ама в повечето случаи се хейти без да се мисли
  7. borovaka

    Linux - обща дискусия 3

    "Алчното говедо" има повече приходи от всякога и вече официално Windows не е приоритет на компанията Проблема е друг вече и то не само с MS - проблема е, че калуд провайдърите не плащат нищо, когато ползват open source продукти. А иначе това, дали ползваш Linux/BSD или Windows на твоята машина - никой не го грее, ама изобщо.
  8. borovaka

    Снимки на Вашия Linux - част 2

    Ами не точно. Реално ако имаш 90% от лаптопите ,които се продават на пазара - които HDMI и DisplayPorts са вързани към Intel картата - няма да трябват никакви настройки. Само драйвера + подходяща версия на Xorg ( с пачовете за offloading) всичко би трябвало да тръгне без никакви конфигурации. Единственото, което трябва да се направи е да се сетват environment variables за апп-а, който ще се пуска с nvidia-a: __NV_PRIME_RENDER_OFFLOAD=1 __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia
  9. borovaka

    Снимки на Вашия Linux - част 2

    NVidia offloading реално работеща ... За сега бачка само под Х. Друг проблем е, че ако портовете за вънпния дисплей са вързани към дискретната карта не става номера (което е напълно нормално ), трябва да се бутне на ръка xorg.conf за да се добави reverse prime конфигурация за да запалят - няма нищо подобно на intel-virtual-output за момента. Иначе като цяло си бачка стъбилно на Fedora 31, кофтито е, че не гаси шината на картата и ~ 2-3 вата има консумация в idle, но не е болка за умиране.
  10. //Offtopic Федора 31 си е ОК, аз я ползвам от известно време. Проблем при нея е, че тъпаците са решили да пуснат CGroups V2 по подразбиране - и Docker не работи - разбира се има kernel option, който оправя нещата. Иначе като цяло е стъбилна и си я ползвам за работа.
  11. От мен странен бъг който забелязах в CentOS 8/Stream - има някакъв странен бъг с дисплея във VMWare - при инсталиран open-vm-tools резолюцията не е ОК ( не репортва хост window size ). Не съм го дебъгвал - така или иначе не го ползвам за desktop. @P2P Аз честно казано не бих инсталирал нещо от рода на CentOS ( което се предполага, че го слагам за стъбилна система ) - и да взимам някакви rpm-и от другаде и да правя някакви магии. За това си има Fedora - и честно казано поне от 4-5 версии си е доста събилна, ако не ползваш бета и не правиш някакви простотии (каквито аз правя често). Междудругото са пушнали и CentOS8 docker base image-a, за LXC още го няма, но мисля, че скоро ще се появи и там
  12. Защо? Убунту до колкото помня си имат PPA - което трябва да overide пакета, който е по подразбиране - освен ако в Минт не правят някаква хамалогия (ама не мисля).
  13. То си пише какво да направиш sudo apt install winehq-stable Ето тук има описание как да инсталираш последната версия на wine: https://wiki.winehq.org/Ubuntu
  14. Опитай със: $ sudo apt install -y wine $ winecfg
  15. Аз изобщо не съм съгласен с твърденията ( като изключим тези за бъговете и code quality ) Иначе, много ясно, че като имаш стандартизация - губиш някакво flexibility - реално не го губиш, защото в сървиса можеш да извикакш какъвто искаш код отдолу - той и пича го е писал, че за по нетипични неща му се налага да пилза скрипт/програма. Това обаче за мен си е чист benefit По-скоро опираме от една страна до манталитет на Developer срещу SysAdmin/User, а от друга до чист hate към проекта и Ленарт. 1) Това, че един проект е OpenSource - не значи - повтарям не значи, че Main development team-a трябва да се съобразява с желания на community-то ( всеки има свободата да го форкне ) 2) RedHat ще си правят каквото искат - имат капацитета/парите/development power-a да го правят - това, че стоят зад SystemD и зад Gnome като цяло им дава пълното право да си интегрират едното с другото както искат 3) Ако някой не се кефи на тези технологии - спокойно може да не ги ползва. Въпросът обаче е, че в крайна сметка всички ги adopt-наха, което е показателно 4) Този hate трябва да спре - реално в момента - всичко що е SystemD, идея на Ленард е кофти! Обаче ако някой се загледа в kernel кода, kernel mailing lista - там мазаляка е брутален за доста неща - обаче никой нищо не казва, защото алтернатива няма 5) Според мен - По-добре да имаш продукт с bad code quality, който да е стандартизиран и интегриран - по простата причина, че кода винаги може да се пренапише читаво, ако имаш изграден интерфейс, който се ползва. Другото е много по-сложно да имаш 1000 интерфейса, които всеки ползва както си иска 6) Що се отнася до INIT състема, стартъп скриптовете според мен трябва да са точно сървиси, с ясна дефиниция и без много волности. Ако има някакъв по-сложен сценарий логиката се оставя на програмиста на сътовтения app, който може да я изнесе в някаква bootstrap програма/скрипт, който да се call-не през сървиса - Това е правилния начин. Като администратор, ако отвориш даден service знаеш какво ще е реално - структура ти е ясна, ако отвориш SystemV скрипт - почваш да се мъчиш да се ориентираш в мазаляка, който някой е решил да сътвори някога. 7) Тази стандартизация ти дава някои интересни свойства - Можеш да sandbox-неш сървиса, можеш да вкараш някакви firewall rules per service и т.н Някой изобщо замисля ли се, че като прокламира постоянно Ричи-Томпсън философията на Unix от 70-те, е възможно не всичко да apply-ва към днешна дата? Примерно да изключим SystemD, bash е удобен много, но от силна отживелица, като имплементация. PowerShell като идея е много по-добре измислен - като conversion-a на командите и аргументите към ясно дефинирани обекти, които имат някакъв ясен behavior. На мен bash ми е по-удоен като интерфейс за работа, въпроса е, че това не значи, че е по-добър като замисъл и имплементация (напротив кода е пълен shit ). Та идеята ми е да не се заклеймява така effort-а на някой, било Ленард/RedHat/Microsoft/Google etc. Ако някой не го кефи нещо да се спасява - има свободата да си форква, модефицира и да прави каквото иска - въпроса е дали effort-а си струва и дали ще е по-ОК неговата имплементация.
  16. Ето малко повече инфо какво точно ще се случва и какви ще са отношенията Fedora -> CentOs Stream > RHEL > CentOS https://fedoramagazine.org/fedora-and-centos-stream/
  17. По-скоро ще правят още един тест на point release на RHEL, според мен
  18. Не е само rolling - CentOS Stream е rolling, има и стабилна версия, която си следва RHEL
  19. За SystemD като цяло ли говориш? Или само за Init часста? Реално SystemD много отдавна не е само Init система
  20. Нещо интересно по темата за SystemD ( реално няма общо със SystemD, но това си е грешна стратегия от бая време на Lennart) : https://streaming.media.ccc.de/asg2019/relive/164 Идеята ми се вижда доста-добра. Проблем има примерно със SSH към машина на която не си логнат локално - след като home partition-a е заключен, реално не можем да направим SSH към дадения User. За това обаче си мисля, че има лесен Workaround, ако има 2 images - единия да е home.username а другия meta.username (който да държи примерно authorized_keys на потребителя ). Така може реално да се напарави SSH към dummy акаунт с рандом UID, който да има право единствено да отключи LUKS-a на съответния User. След това нещата са прости: su - username Та какво мислите вие за идеята?
  21. А можеш ли да обясниш с какво по-точно SMF ( като идея говоря, не като имплементация ) е различен от SystemD? С SRC не съм се сблъсквал до сега, но SMF за мен е с почти 1-1 идея като SystemD. Ако говорим за чистата имплементация, според мен INI стила на SystemD е по-четим от XML-a при писането на сървиси ( ако зависи от мен да го имплементирам - всичоко и навсякъде, за каквито и да е конфигурации трябва да е YAML, но това е друга тема ). Това за корпорациите също не го разбирам ( най-малкото си дал примери с IBM и ORACLE, като алтернативни решения ) - имаше алтернативи преди SystemD да се наложи ( Upstart/SystemV ). Като цяло аз съм точно за налагане на стандарт на абстрацкия върху потребителите ( без значение - обикновен потребител/sysadmin etc. ). Това, че имаш стандарт на имплементация на сървиса - по никакъв начин не ти връзва ръцете за имплементацията на App-a, който ще стартираш през него. Дори напротив, дава ти стандартен и предиктивен начин на работа със ситемата ти. При SystemV беше тотален shit положението, и сървиси се пишеха, на кой както му е кеф - predictability 0. За документацията - до някъде съм съгалсен, че е shit - но в скорошните release, man pages са ОК - поне според мен ( или аз съм привикнал с времето ). Можеш ли да дадеш някакъв по-конкретен аргумент кое по-точно не е ОК според теб? Колкото до авторите аз съм върл фен на Lennart Poettering - че маже кода, няма спор, ама идеите му са ОК, а и има кой да му оправя мазаляка ( в повечто случаи ). А и това пак е много-относително, защото примерно в kernel maling list-ите, ако проследиш дискусии - има доста по-големи мазаници, които се merge-ват upstream. А това ,че има бъгове, които не са оправени много време, си а абсолютно нормална dev процедура. Ако, бъга няма директен security impact и не засяга голяма, част потребители - може да се отложи във времето, ако има лесен workaround - също. Ако за някой е голям проблем в тези случаи - може да си напише patch, или да наеме екип, който да го напише - за пример Facebook правят точно това, точно със SystemD и до колкото се сещам upstream-наха наскоро техни доработки.
  22. LDAC е кодек на Sony, но го ползват и доста други производители. Освен LDAC - aptX-HD/aptX също се поддържат от доста устройства и са с по-добро качество - може да тестваш.
  23. A2DP е профил по-скоро protocol, а аудиото по него върви през кодек, който може да е SBC ( в стандартния, общ случай ), или LDAC ( 3-пъти по-висок битрейт ).
  24. Да споделя, ако на някой му е полезно: Сдобих се наскоро със слушалки, които поддържат LDAC: Sony WH-1000xm3 - Е да, ама кофтито е, че PulseAudio си бута по Default с SBC ( който си е old scholl кодека и държи 320 битрейт). Та в крайна сметка излезе, че Sony са пуснали LDAC opensource, под Apache2 лиценз. За PulseAudio има плъгин, който добавя кодеците: https://github.com/EHfive/pulseaudio-modules-bt За Fedora има RPM в RPMFusion, казва се pulseaudio-module-bluetooth-freeworld Тук има инструкции за инсталиране и на други дистрибуции: https://github.com/EHfive/pulseaudio-modules-bt/wiki/Packages След инсталиране може да се селектира кодека през Gnome Settings -> Bluetooth. Има малка особеност, ако ви трябва да смените quality настройката на LDAC трябва на ръка да се редактира /etc/pulse/default.pa и да се сетне съответната опция към модула - има го описано в README.md на github repo-то. Интересното е , че в момента работи без особени грижи ( като изключим нормалните за PulaseAudio бъгове ) и другото готино е, за момента май май единствено на Linux може да се ползва LDAC при PC - Windows до колкото знам ползва единствено aptX, а Mac AAC. п.с. И само за протокола: това, че кодека поддържа по-висок bitrate не значни, че като слушаме loseless песни ще има особена разлика ... при Spotify примерно максималното качество е 320kbps. За да се осети някаква разлика трябва FLAC, който е рипнат директно.
  • Разглеждащи това в момента   0 потребители

    • Няма регистрирани потребители разглеждащи тази страница.
×
×
  • Добави ново...

Информация

Поставихме бисквитки на устройството ви за най-добро потребителско изживяване. Можете да промените настройките си за бисквитки, или в противен случай приемаме, че сте съгласни с нашите Условия за ползване