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

Melmak R

Лига на легендите
  • Публикации

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

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

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

  1. Съглсен. +1 И трите са добри или най-малкото много интересни. Въпреки че има поводи за размисъл - от типа ако имаше перфектно изпипани апликации, дали изобщо щяха да се ползват контейнери и дали RO се е доказвала изобщо някога. Най-вече, дали не влизаме твърдо в телефонния бизнес - където се подмятат някакви изображения с 85% интелектуален отпадък вътре? Най-малко има поне едно дублиране на графичните библиотеки с тези на самата дистрибуция. След това между отделните приложения вътре във flapak заради подверсиите, както си писал. Има един много хубав начин. Както се разпространява Java Runtime и .Net след нея. Тоест за всички минорни версии се пуска един пакет с библиотеки. Например за GTK 3 да обхваща всички от 3 нагоре, а GTK 4 всички от 4 нагоре. Пак ще има данък дисково пространство, но поне би бил доста минимален. А и няма да има нужда от OSTree. Предполагам, обаче, че не са го направили така, защото щяха да се забават значително време с преправяне на библиотеките.
  2. Не съм съгласен за CoW. Технологията е интересна, но с ограничено приложение за персонални компютри, от което най-много се интересувам. Може би не му е хрумнало по онова време да ги разделя на прости и сложни, както аз правя. Btrfs ми беше доста интересна по едно време. Искаха постепенно да я развиват - хитър подход. Но се оказа, че всичките функции, за които се оглеждах, бяха нещо като "бета" и от тогава не съм я гледал. Изобщо е грешно да имаш бета функция във файлова система. Според мен бетата, проточването на разработката и реда по който вкарваха новите функции, донякъде ги провали. Много съм доволен, че всичките ми външни дискове са на ext4 и включване към нещо различно от Linux е принципно забранено. Така че няма проблеми в това направление. Разбира се, ако си купя нови по-натам, може и ZFS да сложа. Харесва ми, че са предвидили проверка на съдържанието на файловете, което разпространените конкуренти не го могат. Мерси за разясненията. Хубаво са се сетили за версиите. Доста ме ориентира, без да се налага да търся. Само не разбрах един проект ли развива реализацията за Linux или са няколко? Защото имам някакви спомени че са няколко различни, може би греша. Може и така, но при мен въпросния подход издиша със специфичните програми. Тук и аз съм виноват, защото трябваше преотдавна да измисля нещо. И ако бях, нямаше да се мотам толкова с миграциите. Като изключим тях, всичко друго ми е направено за Tombstone Reanimation или поне е мислено за него.
  3. Това добре, но от цялата шумотевица не вдявам няколко неща: 1. Ако искам ZFS в Linux, какво трябва да инсталирам? Кои са двата най-издържани проекта за Linux в момента? 2. Ако реша че ще ползвам ZFS във FreeBSD и Linux, какъв е шанса файловата система да се омаже? А между два различни Linux-а, ако приемем че ползват различни версии или реализации? Дано не. Ненавиждам този подход. А и ми харесва разделението между прости и сложни файлови системи. Тоест предпочитам XFS и EXT4 да си останат елементарни файлови системи с поддръжка на само най-важното. ZFS ме интересува колкото за външните дискове (заради чексумите на данните), евентуално за Root (заради CoW) и евентуално за пренос на данни между FreeBSD и Linux. Като последните две са с малък шанс за употреба. Иначе на даля за данни и home мисля да си карам с EXT4/XFS. Даже сега екпериментално съм минал изцяло на XFS за вътрешния диск. Откакто Росен ми пусна мухата за износването на SSD-тата. И ти си прав и те са прави. Ако на компютъра правиш само едно-две неща в даден момент, тогава не е проблем да сложиш/преминеш на каквото и да е. Даже и Windows. Но я си представи, че си го нагласял половин година и имаш 100-на по-специфични програми. Не е голям проблем да компилираш ядрото по-метода на прекомпилиране на пакета. Тогава с малко четене и смяна само на няколко подбрани опции можеш да се оправиш. Това съм го правил преди цяла вечност на Arch и стана много лесно и бързо. Обаче, ако искаш да минеш на друга версия или да правиш много промени или да го билднеш от друг сорс, тогава вече става много трудно. Защото не можеш да разчиташ на шаблона, пачовете и теста на готовия пакет. Ще има сменени/нови опции и общо взето ще се оплетеш, без да имаш идея дали това чудо ще работи адекватно.
  4. Има идейно развитие. Главното е че въвежда по-твърдо разделение между приложенията и системните компоненти, като добавя практически неунищожими образи при надграждане. Има истина в първото за което ще пиша след малко. За второто не пречи толкова, поне не и в рамките на моя начин на употреба. Така или иначе принципа за рядкото рестариране в Linux е утрепан напълно. Главни заслуги Интел корпорейшън. По-скоро за Desktop има смисъл, както го виждам аз. За сървър една адекватна програма за бекъп + относително кадърен персонал ще са конкуренция, която въпросната технология трудно може да надгради. Но за работен плот, където обикновено не се правят бекъпи, може да представлява интерес. Да, казват че подобни тенденции навлизат масово и като се замисля, може да са прави. Според мен изобретението е интересно. Евентуални проблеми ще са дублирането на библиотеки, големия разход на дисково пространство, може би засилен мережов трафик при обновяване, грубото съчетание на няколко технологии, трудното използване /поради комбинация от технологии и принципи/. Но според мен най-основния минус е че подобна технология евентуално ще окуражи още повече публикуването на софтуер с алфа и пре-алфа качество. По същия начин, както пакетните мениджъри позволиха ада на версиите, модификациите и раздробяването на софтуера. Също е много интересно и противоречито, което се получава със старите принципи, заложени в пактните мениджъри - избягването на дублиране на библиотеки и минимално натоварване на файловата система. При това двете технологии ще работят заедно. Изобщо интересна приумица, която ако се приложи много старателно и внимателно, ще сработи добре. В противен случай следва "Windows of the Linux world".
  5. Melmak R

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

    Хем бъди свободен, хем профешънъл. Ох, как ме напушва смях с тези пазарно-ориентирани определения. Имам в предвид от рода на SUPER, MEGA, ULTRA, ULTIMATE, TITANIUM, EXTREME и т.н.
  6. Да. Интересното е че напоследък им се въртят едни и същи мисли в главата на комерсиалните издатели на дистрибуции. В тази връзка препоръчвам следващото видео. Желателно е неподготвените, хард фенове на Linux да вземат хапче против диария, превантивно! Fedora Silverblue 30 could be the future!
  7. Ох, винаги ще се намери някой да философтва. Ако прехвърляш по този начин, изключваш напълно кеша. Един вид приложението трябва само да прецени в какъв размер и дали да задели кеш, изземайки ролята на ОС. Строго погледнато не важи напълно и за графичните приложения. Но отново възникват съмнения доколко е правилно и по какво приложението да познае как трябва да се държи. Нищо не пречеше да има опция "system" във fastab и всичко щеше да е наред.
  8. И аз съм се интересувал. Наскоро бях попаднал на интересно подхвърляне, как може да се намали. Не беше смислена информация, само случайно подхвърляне, което изгубих. Затова сега се разрових по-подробно да видя какви са възможностите. За съжаление проблемът няма смислено решение на този етап. 🙁 Може да се опита с промяна на някои параметри, но като цяло ядрото е оптимизирано с логика за вътрешни дискове, като дори третира всички дискове по един и същи начин за цалата машина или контейнер. В мрежата е писано за следните параметри, но с тях не се постига желаната задача. hdparm -W 0 /dev/sda # echo "40" > /proc/sys/vm/pagecache vm.vfs_cache_pressure memory.limit_in_bytes Естествено, навсякъде се проповядва, че това поведение е „оптимизирано“ и всъщност точно то е правилното. https://www.linuxatemyram.com/ https://unix.stackexchange.com/questions/210950/content-cached-in-ram-while-writing-to-disk-linux https://unix.stackexchange.com/questions/253816/restrict-size-of-buffer-cache-in-linux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/tuning_and_optimizing_red_hat_enterprise_linux_for_oracle_9i_and_10g_databases/sect-oracle_9i_and_10g_tuning_guide-memory_usage_and_page_cache-tuning_the_page_cache Всъщност поведението е идентично във всички среди и даже в конзолата. Не знам защо мислиш, че е само в GNOME. Не съм пробвал специално под KDE, но се обзалагам че ще е същото.
  9. Да, така е. Мернах някъде, че можеш да промениш някакви параметри за този кеш и да го намалиш. Като изключим това не съм виждал друго решение. Явно няма как средата да получи адекватен статус на прехвърлянето от ядрото.
  10. Melmak R

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

    И DeaDBeeF също може да избира. Виж тук, може секцията за аудиото да помогне: https://wiki.archlinux.org/index.php/Gaming#Tuning_PulseAudio Не че бих искал да адвокатствам в полза на Pulse. Има секция във winecfg, незнам дали си видяла. Съответно избор на драйвър и тестване на драйвъра. Pulse драйвъра трябва да се активира при компилиране или ще липсва. А на много стари версии изобщо нямаше. Така че много фактори са намесени.
  11. Вярно че се пуска, обаче не се натъманява по-лесно. В дефаултната конфигурация, мога да си затрия системна папка през FTP клиента. Пък и е малко бабешки протокол в сравнение с NFS/SAMBA.
  12. Не виждам защо да не стане. На практика компютрите ще се виждат като твърд диск от работата среда и програмите. За писането по всяка папка не бих го направил. Потенциално деструктивно, но няма техническа пречка да се направи. Да. Аз съм 60%/40% в полза на NFS срещу SAMBA. И двете вършат горе долу едно и също. Но за SAMBA има много повече упътвания в интернет, плюс че шерва с Windows в локалната мрежа. Да имаш Linux и да не си билднеш мрежата с него е федерално престъпление. Да, много добра идея. Ако между два от по-малките компютри направи отделна мрежа, ще преовери какви са възможностите, без да разваля нищо. Заради UDP мисля, че NFS ще е по-бърза от FTP. Не че някой ще го гледа чак толкова.
  13. Не точно по-опростено, но се радвам че си се сетил. Защото е известна програмка. Не е по-просто защото е мислено с идея за синхронизация, което само по себе си вече усложнява на фона на FileZilla. Но от rsync вариантите е по-просто и съответно с по-малко възможности. FreeFileSync използва SFTP/FTP/Google Drive. Grsync извиква rsync и ползва неговия протокол. LAN Share не изглежда лошо, но нямам мнение засега. На фона на nistroshare изглежда с малко по-усложнен интерфейс тип торент клиент. Във всеки случай и двете са непретенциозни с възможност да заместят SMB/Dropbox, без да притежават и 1/10 от тяхната функционалност. Доказват, че с прост и издържан дизайн е възможно да се направи нещо подобно. Само ми се щеше да си бяха дали още 5% усилия за развитие. ================================== Забравихме за SSHFS In computing, SSHFS (SSH Filesystem) is a filesystem client to mount and interact with directories and files located on a remote server or workstation over a normal ssh connection. The client interacts with the remote file system via the SSH File Transfer Protocol (SFTP), a network protocol providing file access, file transfer, and file management functionality over any reliable data stream that was designed as an extension of the Secure Shell protocol (SSH) version 2.0. The current implementation of SSHFS using FUSE is a rewrite of an earlier version. The rewrite was done by Miklos Szeredi, who also wrote FUSE. И още една разновидност: rsync daemon rsync can be run as daemon on a server listening on port 873. На фона на NFS не бих ги ползвал в качеството на локален сторидж.
  14. Според мен NFS ще свърши най-добра работа. Обща информация: https://ru.wikipedia.org/wiki/Network_File_System https://www.ibm.com/support/knowledgecenter/ru/ssw_aix_71/com.ibm.aix.networkcomm/nfs_intro.htm Конфигуриране: https://wiki.archlinux.org/index.php/NFS_(Русский) Съвети: 1. Фиксирай IP тата на сървърите през рутера. 2. Затвори портовете в рутера за всички услуги, които ще ползваш във вътрешната мрежа. 3. Не изгаряй всички мостове към Windows. Много вероятно ще ти се прииска да ползваш мрежата под него. Това може да стане и с допълващи програми, така че Windows да е изолиран, но не напълно отрязан. Което е разумно, защото от него могат да дойдат неприятности - например криптовирус. 4. Направи си повечето директории с достъп само за четене. И примерно една две за трансфер. Така ще си по сигурен от случайни грешки и евентуални атаки. 5. Остави само дин-два компютъра да раздават и приемат файловете, а всички останали да четат. Така ще е по-подредено и няма да има нужда от сериозно синхронизиране след време. Това е само предположение, може и да предпочетеш всички да поддържат трансфер, ако повече пасва на твоя маниер на работа. Алтернативи: Разбира се на първо място идва SAMBA. Конкретно е протокол правен от MS за Windows. Минус е че натоварва повече клиентските компютри. Има репутация, че бави повече в Linux и може да изникнат някои несъвместимости, но това е история, която трябва да се препровери. Самата SAMBA има някои функционалн предимства, но не мисля че ще са от значение за случая. Rsync - страхотна програма, но е повече пригодна за инцидентно копиране и синхронизиране. Има интересни и много практични възможности. Минуси: изисква достъп до SSH шел, което е рисковано при неправилна конфигурация. Ползва се от командната линия и командитте са дълги. Не работи с виртуално дърво на директориите, всичко по дисковете се вижда както е. Могат да изникнат проблеми с правата между отделните потребители. Тръдно се ограничава и изолира. Nitroshare - малка програма, която може да избутва файлове и директории. Изцяло графична, мултиплатфомена - Linux, Mac, Windows. Минуси: разчита само на UDP протокола за проверка на цалостта на файловете. Не може да раздава файлове на принципа клиент-сървър. Scp - също много известна, класическа, конзолна програма за прехвърляне на файлове. Удобна за единични файлове и инцидентни прехвърляния по LAN. Същите недостатъци като RSYNC. FTP - класическа програма за прехвърляне на файлове. Удобна е защото има графични клиенти. Минуси: много слаба сигурност, всеки който е в мрежата може да види паролата. Освен това проверката на интегритета на файловете е слаба - разчита изцяло на TCP протокола. Интересното е че има два режима на прехвърляне - текстов и бинарен, които зависят от клиента. Ако клиента реши, че даден файл е текстов и го прехвърли по този начин, може да повреди файла. Тъй като това зависи от клиента, подобна повреда е лесно да се случи. SFTP - Пртокола е същия, като FTP, но ауторизацията и прехвърлянето се осъществяват през SSH протокола. Интегритета на файловете е практически невъзможно да се наруши. Притежава всички предимства на FTP. Минуси: И тук присъства текстов/бинарен режим на прехвърляне. И тук се преминава през SSH шела с който трябва да се внимава откъм сигурност. Програмите за сървър са сравнително малко. Евентуални проблеми с позволенията между отделните потребители. Проблеми с ограничаването и виждането на цялото файлово дърво на сървъра. FTPS - Това е протокол който много прилича по възможности на SFTP. За разлика от него, обаче е малко по-различен. Поддържа се от програмата vsftpd, което позволява виртуално дърво на директориите. HTTP - Обикновения Web сървър може да се настрои така, че да генерира страница с линкове към файловете. Много е удобно за Download на файлове. В комбинация с някои опростени сървъри може да се активира за под минута. Допълнително удобство е че така може да раздава видеофайлове и музика към портативни устройства или телевизори. Минуси: За проверка на файловете се използва IP протокола. В много редки случаи могат да възникнат грешки в трансфера. Като цяло не поддържа ъплоуд и се подслушва лесно. Някои от компактните сървъри могат да са по-податливи на мрежови атаки. Nextcloud - Това е софтуер предназначен за създаване на локален облак и замяна на фирмените решения. Поддръжа и трансфер на файлове, работи най-вече през браузър. Минуси: според мен трансфера се осъществява през IP протокола, може би HTTPS но не съм проверявал. Инсталира се по-трудно. Като цяло най-подходящи ми изглеждат NFS в комбинация с Nitroshare и HTTP за Windows или портативни устройства. За инцидентно копиране, тройката rsync/scp/sftp също е добра. По едно време доста си играх да ги направя абсолютно универсални, но конфигурацията на файловото дърво, позволенията и сигурнстта са предизвикателство, което тогава не успях да постигна. А и са по-бавни от UDP базираните NFS/Nitroshare. От трите съм най-доволен от rsync. Надминава очакванията в пъти. Най-надеждна и с най-много опции. Швейцарско ножче за копиране на файлове, което ползвам даже и за локално копиране по твърдите дискове, когато се налага допълнителна функционалност. NFS не съм пускал лично, но предполагам ще оправдае очакванията.
  15. Ново бъгче в Arch. Възможно е да ви излезе грешка symbol 'grub_file_filters' not found и да не стартира нормално. Съветвам или да не обновявате сега, или да внимавате с GRUB2.
  16. Melmak R

    Задаване на sudo потребител в Debian

    По този начин не виждаш програми, които би било смислено да се извикват само под root. На мен ми се е случвало да се бъркам - извиквам системна програма и тя да ме отреже заради правата. Така е че по-интересно и бих казал смилено, както са го направили сега, но може да има усложнения. Практически, трябва да се усетиш да залепиш "su -" и т.н.
  17. Melmak R

    Задаване на sudo потребител в Debian

    Говори се че има разлики, като настройки в инсталациите в зависимост от това, какъв инсталатор е използван. Може би и в неговия случай се получава нещо подобно.
  18. Объркал съм се, но не мога да редактирам стария пост. Последно трябва да е: Защото е C сорс код.
  19. Даже не съм видял шибанг-а отпред. Не се лъжеш. Деиствително с # се игнорира. Обаче, когато е по начало закоментирано, показва конфигурацията по подразбиране. Недей, трябва да е: Иначе пак ще е изключено. Разбира се, виж какво е написал @Тамболианеца за default_options.h . Може би там е по-правилно да го активираш.
  20. Виж това да не ти разваля играта: https://git.archlinux.org/svntogit/community.git/tree/trunk/localoptions.h?h=packages/dropbear localoptions.h ....................... /* * Arch Linux configuration for DropBear ........................ /* Disable X11 forwarding on the server */ #define DROPBEAR_X11FWD 0 Явно и Arch Linux са го изключили.
  21. Ако Фейсбък или службите се интересуват, могат да го разберат по всяко време. Ако е въпрос за случайни хакери - по-трудно, но пак не е абсолютно изключено.
  22. Той принципно е привърженик на идеята, че KDE натоварва малко. Аз се смея, защото обяснението е като за .NET форум. Всичко е „ултра“ оптимизирано и бързо, спете спокойно. И да не ви хрумне да почнете да го сравнявате с разни други решения. Всъщност, цялото дърпане на ресурси идва от GTK3 фреймуърк-а. Разработчиците на XFCE и да искат няма какво да направят в момента. Между другото Плазмата също не е оптимизирана за бързодействие и ресурси. Аз оставам с впечатлението че тях ги интерусува само да им работят техните неща и да е красиво, а всичко останало няма особено значение. Без детаилно разглеждане къде отиват, цифрите нямат особено значение. Ако примерно отиват 20 MB за Baloo, трябва ли да ги броим и тях към KDE-то? Според мен не, файловите индексатори са ужасна идея и са доказали че работят лошо /Baloo, Spotlight, search indexing и т.н./.
  23. Melmak R

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

    Debian 10 и Fedora са възможни. KDE и да не се получи, не е толкова важно. Идеята е да се грижа колкото може по-малко. Mageia и openSUSE са интересни, но като че ли не ми се ще, заради пакетите им. Като гледам са диалект на rpm, който ми идва малко по-тежък. Debian 9 отпада автоматично. Не хващам дългата поддръжка, а с остарели пакети само ще се измъча. Според мен е повече за хора, които обръщат внимание на детайлите и мофицирането на работните среди. А мен не ме тегли в тази посока. =========================================== Merging exFAT Support For Linux Is Being Talked About - Waiting On Microsoft's Blessing http://www.phoronix.com/scan.php?page=news_item&px=Linux-exFAT-2019-Discussion Сега става интересно. Не е лоша идея да им дадат малко жега. Да видим как и дали ще продължат да занасят. shmerl @ https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1112623-merging-exfat-support-for-linux-is-being-talked-about-waiting-on-microsoft-s-blessing?p=1112648#post1112648
  24. Melmak R

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

    Вече съм се настроил да сменям дистрибуциите, докато не попадна на нещо смислено. Само няма да е Arch, това е сигурно. Все пак, благодаря за предупреждението. Xfce-то и аз го харесвам, но мисля поне временно да го оставя на втори план. Най-вече за отдалечена връзка и резервна среда.
  25. Melmak R

    Дотук беше с бозата!

    Не съм съгласен с казаното и най-вече за процентите. Apple наистина могат да са голама мафия, но същото важи и за останалите. Началната цена на лаптопите не е нещо изненадващо , предвид какви части слагат. Кастрирани - при всички хубави лаптопи на които би се спрял, трябва да правиш компромиси. Признавам, обаче, много ме дразни че са премахнали Del клавиша, че са сложили биометрия, че са заместили функционалните с онова "нещо" отгоре, че нямат LAN конектор и нормален твърд диск. Всяко от тези неща реално би ме спряло от покупка, ако се замислях.
  • Разглеждащи това в момента   0 потребители

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

Информация

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