Премини към съдържанието
  • Добре дошли!

    Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

    Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

     

luckyboy

Новини от света на Linux дистрибуциите.

Препоръчан отговор


на 28.07.2019 г. в 11:05, Тамболианеца написа:

А като рестартираш - я камилата, я камиларя и да влезеш в цикли на ролбеци.

Ммм това не е така. Точно това е идеята по принцип. Реално винаги имаш 2 ReadOnly OS Images - единия ти е с update ,другия е текущия state. След update при рестарт boot-ваш update-натия image, ако не сработи, си гарантираш, че имаш стария state, който е работил и си сигурен, че ще запали.
Идеята е готина като цяло - имплементацията - специално на silverblue е далеч от използваема все още (макар ,че с fedora toolbox си бачка и за development и е ще-годе удобно),

на 28.07.2019 г. в 13:50, Melmak ® написа:

Евентуални проблеми ще са дублирането на библиотеки, големия разход на дисково пространство, може би засилен мережов трафик при обновяване, грубото съчетание на няколко технологии, трудното използване /поради комбинация от технологии и принципи/

Реално дублиране няма да имаш - OSTree, на който е стъпил flatpak има deduplication механизъм. Дублирането идва от там ,че различни приложения могат да таргетират различни SDK-та - примерно flatpack-a на gedit да иска "GNOME Application Platform version 3.30" а на Nautilus да таргетира примерно "GNOME Application Platform version 3.32". Не съм много убеден дали има някакъв  deduplication на файлове между зависимостите - ама мисля, че е възможно да се направи.
 

на 28.07.2019 г. в 10:34, Melmak ® написа:

Желателно е неподготвените, хард фенове на Linux да вземат хапче против диария, превантивно!

Това пък защо? Аз от бая време ползвам Linux - върши ми доста добра работи, но изобщо нищо не ми пречи да го псувам постоянно :)


Иначе специално Containers/Flatpak концепцията + RO System си е мега добра според мен. За дистрибутиране на software и development е перфектна. Имаш ясен versioning, който ти гарантира predictability. Ако нещо на версия latest/1.2.0 се счупи хардкодваш 1.1.0 - и си гарантираш ,че винаги ще работи - в класическа система сме далеч от това.
От друга страна като developer, искам да таргетирам LTS версия на lib X, която е примерно 1.1.1 , в момента, ако тоя дето прави дистрото реши да update-не на 2.0.0 - трябва да си портна app-a, а той реално си работи ОК с LTS-a. И обратното, мога да искам да таргетирам upstream,  версия на Library.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 16 часа, borovaka написа:

Идеята е готина като цяло - имплементацията - специално на silverblue е далеч от използваема все още (макар ,че с fedora toolbox си бачка и за development и е ще-годе удобно),

Съглсен.

преди 16 часа, borovaka написа:

Това пък защо? Аз от бая време ползвам Linux - върши ми доста добра работи, но изобщо нищо не ми пречи да го псувам постоянно :)

+1 :D

преди 16 часа, borovaka написа:

Иначе специално Containers/Flatpak концепцията + RO System си е мега добра според мен.

И трите са добри или най-малкото много интересни. Въпреки че има поводи за размисъл - от типа ако имаше перфектно изпипани апликации, дали изобщо щяха да се ползват контейнери и дали RO се е доказвала изобщо някога. Най-вече, дали не влизаме твърдо в телефонния бизнес - където се подмятат някакви изображения с 85% интелектуален отпадък вътре?

преди 16 часа, borovaka написа:

Реално дублиране няма да имаш - OSTree, на който е стъпил flatpak има deduplication механизъм. Дублирането идва от там ,че различни приложения могат да таргетират различни SDK-та - примерно flatpack-a на gedit да иска "GNOME Application Platform version 3.30" а на Nautilus да таргетира примерно "GNOME Application Platform version 3.32". Не съм много убеден дали има някакъв  deduplication на файлове между зависимостите - ама мисля, че е възможно да се направи.

Най-малко има поне едно дублиране на графичните библиотеки с тези на самата дистрибуция. След това между отделните приложения вътре във flapak заради подверсиите, както си писал.

Има един много хубав начин. Както се разпространява Java Runtime и .Net след нея. Тоест за всички минорни версии се пуска един пакет с библиотеки. Например за GTK 3 да обхваща всички от 3 нагоре, а GTK 4 всички от 4 нагоре. Пак ще има данък дисково пространство, но поне би бил доста минимален. А и няма да има нужда от OSTree. Предполагам, обаче, че не са го направили така, защото щяха да се забават значително време с преправяне на библиотеките.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 1 час, Melmak ® написа:

Както се разпространява Java Runtime и .Net след нея. Тоест за всички минорни версии се пуска един пакет с библиотеки. Например за GTK 3 да обхваща всички от 3 нагоре, а GTK 4 всички от 4 нагоре.

Ако е така, когато имаш security issue в някоя версия на библиотека - ще я принесеш навсякъде. При ostree подходя,  ако има проблем с версия на библиотека - update-ваш само нея и би трябвало app-овете, които я ползват patch-натата версия.
Сега друг е въпроса, който прави пакетите какви своеволия е правил :)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 2 часа, borovaka написа:

Сега друг е въпроса, който прави пакетите какви своеволия е правил :)

Много точно казано.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 15.08.2019 г. в 20:48, borovaka написа:

Ммм това не е така. Точно това е идеята по принцип. Реално винаги имаш 2 ReadOnly OS Images - единия ти е с update ,другия е текущия state. След update при рестарт boot-ваш update-натия image, ако не сработи, си гарантираш, че имаш стария state, който е работил и си сигурен, че ще запали.

 

У Федора май сега откриват топлата вода за връщане на ОС към предишно състояние, но го правят на по-ограниченото ниво - пакетен менъджер.
Тази функционалност я има от доста години, десетилетие даже - и в ZFS, и в Btrfs, но пък на по-обхватното файлово ниво.
Мисля си, от Федора да бяха я имплементирали тази функционалност директно в XFS щеше да по-добре, напъните за продължение живота на отживелицата еxt2/3/4 не си заслужават усилията. В същото време колко са другите що-годе използвани файлови системи, различни от споменатите по-горе, и от значение та да са облжат и те от rpm-ostree? В допълнение, как би изглеждала една ОС в светлината на възстановяване на предишно състояние, и която официално поддържа различни паралелни пакетни менъджъри и инсталатори - rpm-ostree, dnf, yum, rpm, flatpak, snap, make?? Сещам се за израза 'манджа с грозде'.


Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 58 минути, Тамболианеца написа:

У Федора май сега откриват топлата вода за връщане на ОС към предишно състояние, но го правят на по-ограниченото ниво - пакетен менъджер.
Тази функционалност я има от доста години, десетилетие даже - и в ZFS, и в Btrfs, но пък на по-обхватното файлово ниво.
Мисля си, от Федора да бяха я имплементирали тази функционалност директно в XFS щеше да по-добре, напъните за продължение живота на отживелицата еxt2/3/4 не си заслужават усилията. В същото време колко са другите що-годе използвани файлови системи, различни от споменатите по-горе, и от значение та да са облжат и те от rpm-ostree? В допълнение, как би изглеждала една ОС в светлината на възстановяване на предишно състояние, и която официално поддържа различни паралелни пакетни менъджъри и инсталатори - rpm-ostree, dnf, yum, rpm, flatpak, snap, make?? Сещам се за израза 'манджа с грозде'.

Мне. Не са се сетили сега у Федора :) FS snapshot няма общо с OSTree.

При FS snapshot, дали е ZFS/Btrfs/LVM/Stratis( като последните 2 са точно RH технологии, така, че от Fedora са наясно с идеята ) - имаш някакъв някаква delta с промени на файлове, които директно apply-ваш към някакъв state.
При ОsTree е друга схема - имаш Read Only image с някаква Graph структура, като е GIT. От там когато правиш update знаеш точно каква е delta-та с пакети, които трябва да се изтеглят за да направиш от текущия Image нов - update-нат. След като ти се apply-не update - се билдва, нов image, който също е Read Only, новия image се слага за default boot,  a стария отива за secondary - по този начин си гарантираш, че дори да ти се омажат update винаги ще имаш система, която ще boot-не.
Това което си писал с различните package managers - не е никаква драма, защото просто други package managers ( освен Flatpak, който инсталира приложенията в потребителските folders ) НЯМА :)
Ако ти трябва някакъв пакет в Main OS-a имаш врътка да го include-неш в нов Image, който да apply-неш като Update. Но като цяло идеята е да имаш ReadOnly main OS и всичко друго да са контейнери и Flatpack app-ове.
Ако ти е интересно можеш да разгледаш Fedora Toolbox как бачка https://github.com/debarshiray/toolbox - реално е правен за Fedora Atomic ( поново му Silverblue ), но работи и на нормална Fedora Workstation и на всичко което може да пусне Podman. Това реално ти дава вече mutable container с Fedora, който можеш да ползваш за development и да си инсталираш, какво искаш - готиното е, че run-ва като User и нямаш никаква ескалация на Permissions + ReadOnly Main OS ти гарантира, че каквото и да мажеш в toolbox instance няма да повлияе на Мain OS-a.

Като цяло идеята не е нова де - Project Atomic е от бая години, CoreOS (който наскоро RH купиха ) също - кофтито е имплементацията за момента - Flatpak има някой проблеми все още, няма достатъчно пакетиран Software и т.н. ама ще е готино ако нещата се случат. Лично аз мисля, че е доста добър замисъл.

Иначе идеята е доста стара и я беше описал Leonard Poettering ( моя човек :)http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html - интересно, четиво е в общи линии, ако на някой му се занимава да чете - от там доколкото се сещам тръгна Flatpak концепцията като цяло.
 

п.с.
Сега най-вероятно ще скочат някакви хора точно заради Leonard Poettering :) Аз на тоя човек страшно му се кефя на идеите и Avahi/PulseAudio/SystemD/casync
Говоря за идеи - имплементацията му може и да е пълно лайно ( не ми дреме особено, щото има кой да го псува и да му оправя бакиите :)) - ама точно с тия идеи Linux се промени последните 6-7-8 години към много по-добро отколкото беше.
И да не ми говорят разни хора, колко е яко да пиша Bash Scripts както сваря и да си ги ползвам в Init system, или колко е яко да си наконфиш Alsa-та и да switch-ваш manual source ( или да пишеш шантав udev rule или друг shitty script ).

 

п.с. 2 На който му е интересно специално за SystemD може да погледне 

 Много готини концепции са вкарани за Process Isolation - Process firewall-инг/Dynamic PID/File access restriction - etc и ползват CGroups и Namespaces - Реално можеш да си направиш сървиса да има същата изолация като Container, а Process Firewall не сме имали никога реален до сега в Linux ( изключваме Shit-a да run-ваш процеса като някакъв special user и да ползваш iptables -m owner )

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

  Ч.Р.Д.

330px-Tux.svg.png

Linux на 28 години.

И малко история:

https://www.opennet.ru/opennews/art.shtml?num=51355

Ядро 0.0.1    -     само 62 KB  и около 10000 реда код

Ядро 5.3       -      над 25 млн. реда.         :)

 

А Unix     -   на 50 г.

https://www.opennet.ru/opennews/art.shtml?num=51348

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 2 часа, бат'начо написа:

Телефон с отворен код, нещо което аз бих си купил (все още нямам умнофон).

А дано, ама надали. След провала на отвсякъде превъзхождащото си за времето МееGo спрямо Windows Mobile & Android съм доста скептичен & песимистичен към подобни пробиви в статуквото.

Редактирано от Тамболианеца (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
на 6.09.2019 г. в 22:07, Тамболианеца написа:

А дано, ама надали. След провала на отвсякъде превъзхождащото си за времето МееGo спрямо Windows Mobile & Android съм доста скептичен & песимистичен към подобни пробиви в статуквото.

Сега мисля, че ще почне да се получава, покрай Librem проекта. Принципната грешка на Linux, а и на другите отворени проекти е че вкарват прекалено много принципи още от първия път. И с отворен код, и сигурен, и достъпен, и издържлив, и с вечна поддръжка, и т.н. А би трябвало да пуснат нещо прилично, което да надграждат или варират по-нататъка...

на 16.08.2019 г. в 15:15, borovaka написа:

Ако е така, когато имаш security issue в някоя версия на библиотека - ще я принесеш навсякъде.

Не, няма според мен, но както и да е. Ще се пренесе, ако е както в Mac, бившето PC-BSD и донякъде с универсалните пакетни мениджъри в Linux /AppImage, Snappy/, където библиотеката ходи с инстанцията на приложението.

Съвсем отделен е въпросът, че дори и тогава негатвите не са чак толкова унищожителни, колкото се популяризираше в миналото.

на 16.08.2019 г. в 22:48, Тамболианеца написа:

XFS щеше да по-добре, напъните за продължение живота на отживелицата еxt2/3/4 не си заслужават усилията.

:D

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Ubuntu 19.10 ще стартира по-бързо с използването на LZ4 компресия:

https://software.kaminata.net/it-novini/ubuntu-19-10-shte-startira-po-barzo-s-izpolzvaneto-na-lz4-kompresia/

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Clear Linux на Intel свали времената за зареждане на ядрото от 3 секунди на 300ms:

https://software.kaminata.net/it-novini/clear-linux-na-intel-svali-vremenata-za-zarezhdane-na-yadroto-ot-3-sekundi-na-300ms/

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Излезе CentOS 7.7 (1908):

https://lists.centos.org/pipermail/centos-announce/2019-September/023405.html

KEsRjIs.png

А след седмица се очаква и CentOS 8:

https://wiki.centos.org/About/Building_8

Класика. Дистрото е живо. :D

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Ето, така се прави манипулация, евала -"дистрото е живо". Направо му паднаха акциите на борсата с 3 пункта. Сега го удари с дронове, пардон тронове, и гледай да не се качи на тях. :D

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Яяяяяяяя 8 са преминали на rolling release ...................CentOS Stream is a rolling release distribution that acts as a middle ground between the cutting edge packages in Fedora and the stable, long-term packages available in Red Hat Enterprise Linux. Both editions of CentOS are available in off-line and net-install (boot) editions. Additional information can be found in the release announcement and in the release notes (

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
преди 1 минута, Ивайло Димов написа:

Яяяяяяяя 8 са преминали на roling release ...................CentOS Stream is a rolling release distribution that acts as a middle ground between the cutting edge packages in Fedora and the stable, long-term packages available in Red Hat Enterprise Linux. Both editions of CentOS are available in off-line and net-install (boot) editions. Additional information can be found in the release announcement and in the release notes (

Не е само rolling - CentOS Stream е rolling, има и стабилна версия, която си следва RHEL

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Още една интересна OpenRC Арч базирана дистрибуция,която според мен ще си заслужава да се пробва.

https://distrowatch.com/table.php?distribution=hyperbola

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Да видях ,то Stream  е новото случая .......явно се опитват да се харесат на потребителите ,които харесват този тип ОС .

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
току-що, Ивайло Димов написа:

Да видях ,то Stream  е новото случая .......явно се опитват да се харесат на потребителите ,които харесват този тип ОС .

По-скоро ще правят още един тест на point release на RHEL, според мен :)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
току-що, ТерминалТора написа:

Още една интересна OpenRC дистрибуция,която според мен ще си заслужава да се пробва.

https://distrowatch.com/table.php?distribution=hyperbola

Арч базирана........не виждам с какво да е по различна освен със 32 битовата поддръжка............

току-що, borovaka написа:

По-скоро ще правят още един тест на point release на RHEL, според мен :)

Е те си имат Федора за тази цел........не виждам защо се отделят ресурс ,време и пари..................Ма пък и са достатъчно силна компания ,за да могат да си позволят 2 тестови дистрибуции :) 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Хубавото е че поддържа и 32 битови системи. Като трябва да съживявам някой стар кошник вече доста намалява избора на дистра. 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Добавете отговор

Можете да публикувате отговор сега и да се регистрирате по-късно. Ако имате регистрация, влезте в профила си за да публикувате от него.

Гост
Напишете отговор в тази тема...

×   Вмъкнахте текст, който съдържа форматиране.   Премахни форматирането на текста

  Разрешени са само 75 емотикони.

×   Съдържанието от линка беше вградено автоматично.   Премахни съдържанието и покажи само линк

×   Съдържанието, което сте написали преди беше възстановено..   Изтрий всичко

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Добави ново...