Το thread του Fedora

[manosdoc]

Δεν το χαλάς καθόλου. Το TLP το σκέφτηκα από την αρχή αλλά σαν κλασικός τεμπέλης λέω 2 εντολές και τελείωσα με τα powersavings στο λάπτοπ!
Αν δω πάντως κάτι στραβό θα το αναφέρω. Το λάπτοπ είναι καρα-generic CLEVO (αυτά που έδινε το πλαίσιο πριν 2 χρόνια) με stock BIOS οπότε ταρζανιές δεν παίζουν.
Προς το παρόν όλα καλά. Ούτε κάποιο πρόβλημα, ούτε Problem-report όυτε το SELinux μου βγάζει κάνα κουλό.
Θα το κρατήσω με το ταλιμπανικό rawhide 28. Βολεύτηκα και επιτέλους ξεφορτώθηκα τα Windows 10 που από αρχής Windows 8 έχουν αρχίσει να παίρνουν την κατηφόρα στο Desktop Usability και γίνονται ένας αχταρμάς, αλλά αυτό είναι off-topic. Keeper η Fedora.

- - - Updated - - -


F28 Rawhide Gnome 3.26, Ubuntu fonts

- - - Updated - - -

Βγήκε η Fedora 27 Beta
https://lists.fedoraproject.org/arch...7YCP25ABYTWLL/


Κατεβάζετε από εδώ
https://getfedora.org/el/workstation/prerelease/

[shadowman]

Κατέβασα κανονικά όλο τον κατάλογο των Google fonts από εδώ.
https://fonts.google.com/
Φανταστικά fonts!

πολύ πράμα!

Για πείτε τι επιλογές σε rendering κάνατε;
Εγώ απλά πράγματα sub-pixel rendering και hinting slight. Έχετε κάτι για πρόταση;
Τα msft fonts που τα βρήκες;

1)
slight/grayscale ή none/rgb

2)
http://mscorefonts2.sourceforge.net/
με εγκατάσταση μεμονωμένου πακέτου rpm

rpm -i https://downloads.sourceforge.net/project/mscorefonts2/rpms/msttcore-fonts-installer-2.6-1.noarch.rpm

ή από εδώ https://rpmfind.net/linux/RPM/source...-1.noarch.html με browser

[shadowman]

Υπάρχει εύκολος τρόπος να έχουμε secure boot μαζί με nvidia driver (με nouveau υπάρχει συμβατότητα out of the box); Το desktop μου έχει Win 10 και fedora 26, έχω απενεργοποιήσει το secure boot στο bios, υπάρχει πρακτικά κάποιο όφελος αν το έχω ενεργοποιημένο;

-Η ασφάλεια του secure boot σε linux βασίζεται σε ένα άτομο; Κάθε μήνα κάνει την ακόλουθη δήλωση ο developer που το υλοποίησε για το fedora και άλλες διανομές:

Spoiler:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

pjones' statement about Secure Boot on 2017-10-05:

I'm involved in Secure Boot signing in various distros in several ways.

I wrote and maintain pesign ( https://github.com/rhinstaller/pesign ),
which is used for signing EFI binaries, and I'm one of the upstream
maintainers of shim ( https://github.com/rhinstaller/shim ), which most
Linux distros use to transition from the firmware's security domain to the
kernel's. I'm also responsible for Fedora and RHEL's builds of pesign,
shim, and grub2. I'm not responsible for the kernels for RHEL or Fedora,
nor for determining which of them finally get signed for Secure Boot. I
have been responsible for generating keys for signing Fedora's binaries.

As the guy who gets shim signed for Fedora:

At no point have I been contacted with warrants of any kind, or any
similar instrument, or in any way, from governmental or non-governmental
entities, about inclusion of any kind of malware or backdoor in Fedora's
signed secure boot binaries, including shim, grub2, the kernel, and pesign,
nor have I at any time been approached about disclosure of our signing
keys. I am also not aware of anyone else involved in our signing that has
been contacted with warrants of any kind, or any similar instrument, or in
any way, from governmental or non-governmental entities, about inclusion of
any kind of malware or backdoor in Fedora's signed secure boot binaries,
including shim, grub2, the kernel, and pesign, nor am I aware of any other
involved party having at any time been approached about disclosure of
our signing keys.

As the guy who gets shim signed for RHEL:

At no point have I been contacted with warrants of any kind, or any
similar instrument, or in any way, from governmental or non-governmental
entities, about inclusion of any kind of malware or backdoor in RHEL's
signed secure boot binaries, including shim, grub2, the kernel, and pesign,
nor have I at any time been approached about disclosure of our signing
keys. I am also not aware of anyone else involved in our signing that has
been contacted with warrants of any kind, or any similar instrument, or in
any way, from governmental or non-governmental entities, about inclusion of
any kind of malware or backdoor in RHEL's signed secure boot binaries,
including shim, grub2, the kernel, and pesign, nor am I aware of any other
involved party having at any time been approached about disclosure of
our signing keys.

As a person involved in CentOS signing in an advisory role:

I am not aware of anyone else involved in our signing that has
been contacted with warrants of any kind, or any similar instrument, or in
any way, from governmental or non-governmental entities, about inclusion of
any kind of malware or backdoor in CentOS's signed secure boot binaries,
including shim, grub2, the kernel, and pesign, nor am I aware of any other
involved party having at any time been approached about disclosure of
CentOS's signing keys.

As the upstream maintainer of pesign and an upstream maintainer of shim:

At no point have I been contacted with warrants of any kind, or any
similar instrument, or in any way, from governmental or non-governmental
entities, about inclusion of any kind of malware or backdoor into either
shim or pesign. I am also unaware of any other contributor to shim or
pesign having been contacted with warrants of of any kind, or any
similar instrument, or in any way, from governmental or non-governmental
entities, about inclusion of any kind of malware or backdoor into either
shim or pesign.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZ1mjlAAoJEO7SZrcPT+8QoEwQAIK3qU3AZBPyMQahecmfzL8S
gcZUBwfndVx3s/4jB1VaIXurLGY9ZaPlwZ704yZSH+W5/hpNdiGOilJ7dj7T7Md6
mgHrABOaeUb1gyvq1SY85+bjCM5x3Y49Et1Acsr35LeZE8QO4omo8ZTEhYFwxc1v
FtGFS8B9SojN579d3Zd1jdE9jiSO5GMXhaDvAI7pY0AFDOxnLweXx0Wq9eDZX8IT
Z4swr51xpDTQI6PM65JfdCKQi+p6m7PTOu6Tk71eMhM2i3JMveja2XnDjVflIYnu
IdhKPLKpXQOS26vtrQpTGgQ5C+ujo6WPguxZGtuipwcSGoXa618G7PGCbyEAZlMH
/xdy9nT34Ik1/99lllUQQxvaxcwE406KtweR9Nrm8lJCpwHvVp+WjB4mx7fDuSrJ
9fwRW1Ehm930G/Tg//C4arkb5tyeUK2yt7G/iH51cLsLoQiuKXlVJ7TfeDTwi4D6
UIl9biZFBfm4GZSPuyRmXwcXxMegp1jTaHiMqAxFhmaLuBixfGJ91+w7unvEB+YN
8ADz8J2sByR15WMP59E2NuYpl2wXCk45v2nLjjwQUBuXfHSv7ThrYqxfr5KPIt1/
7aPUVfJrkZAmsYLHod6/KYwOF3PwWGNKdPDQ747Kp+VunmlDM7tLjXzPzO7Z49OL
LuLnI1LaY71QczuC1z6T
=4/kx
-----END PGP SIGNATURE-----

https://blog.uncooperative.org/blog/.../05/shim-info/

[manosdoc]

Πρακτικά σου λέει, αν είναι ενεργοποιημένο, τότε drivers μη signed με το Platform key δεν σηκώνεται.
Προσφέρει ασφάλεια αλλά νομίζω κάποια κλειδιά έχουν διαρρέυσει.
Προσωπικά το έχω απενεργοποιημένο και εύχομαι στο μέλλον να μην υπάρχει καν αυτό το feature.
Επίσης επειδή αρχικά τα κλειδιά της Microsoft μόνο υπήρχαν και αυτό θα οδηγούσε σε μη δυνατότητα φόρτωσης λειτουργικού Linux, προτάθηκε να δημιουργηθούν κλειδιά για το Linux αλλά η ευθύνη για την ενσωμάτωσή τους βάρυνε τους OEMs και όλοι ξέρουμε που οδηγεί αυτό.

Spoiler:

The UEFI 2.3.1 Errata C specification (or higher) defines a protocol known as secure boot, which can secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature. The mechanical details of how precisely these drivers are to be signed are not specified.[46] When secure boot is enabled, it is initially placed in "setup" mode, which allows a public key known as the "Platform key" (PK) to be written to the firmware. Once the key is written, secure boot enters "User" mode, where only drivers and loaders signed with the platform key can be loaded by the firmware. Additional "Key Exchange Keys" (KEK) can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the Platform key.[47] Secure boot can also be placed in "Custom" mode, where additional public keys can be added to the system that do not match the private key.[48]

Secure boot is supported by Windows 8 and 8.1, Windows Server 2012, and 2012 R2, and Windows 10, VMware vSphere 6.5[49] and a number of Linux distributions including Fedora (since version 18), openSUSE (since version 12.3), RHEL (since RHEL 7), CentOS (since CentOS 7[50]) and Ubuntu (since version 12.04.2).[51] As of January 2017, FreeBSD support is in a planning stage

In August 2016 it was reported that two security researchers had found the "golden key" security key Microsoft uses in signing operating systems.[112] Technically, no key was exposed, however, an exploitable binary signed by the key was. This allows any software to run as though it was genuinely signed by Microsoft and exposes the possibility of rootkit and bootkit attacks. This also makes patching the fault impossible, since any patch can be replaced (downgraded) by the (signed) exploitable binary. Microsoft responded in a statement that the vulnerability only exists in ARM architecture and Windows RT devices, and has released two patches, however, the patches do not (can not) remove the vulnerability, which would require key replacements in end user firmware to fix.

Από wikipedia

[shadowman]

Πρακτικά σου λέει, αν είναι ενεργοποιημένο, τότε drivers μη signed με το Platform key δεν σηκώνεται.
Προσφέρει ασφάλεια αλλά νομίζω κάποια κλειδιά έχουν διαρρέυσει.
Προσωπικά το έχω απενεργοποιημένο και εύχομαι στο μέλλον να μην υπάρχει καν αυτό το feature.
Επίσης επειδή αρχικά τα κλειδιά της Microsoft μόνο υπήρχαν και αυτό θα οδηγούσε σε μη δυνατότητα φόρτωσης λειτουργικού Linux, προτάθηκε να δημιουργηθούν κλειδιά για το Linux αλλά η ευθύνη για την ενσωμάτωσή τους βάρυνε τους OEMs και όλοι ξέρουμε που οδηγεί αυτό.

Spoiler:

The UEFI 2.3.1 Errata C specification (or higher) defines a protocol known as secure boot, which can secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature. The mechanical details of how precisely these drivers are to be signed are not specified.[46] When secure boot is enabled, it is initially placed in "setup" mode, which allows a public key known as the "Platform key" (PK) to be written to the firmware. Once the key is written, secure boot enters "User" mode, where only drivers and loaders signed with the platform key can be loaded by the firmware. Additional "Key Exchange Keys" (KEK) can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the Platform key.[47] Secure boot can also be placed in "Custom" mode, where additional public keys can be added to the system that do not match the private key.[48]

Secure boot is supported by Windows 8 and 8.1, Windows Server 2012, and 2012 R2, and Windows 10, VMware vSphere 6.5[49] and a number of Linux distributions including Fedora (since version 18), openSUSE (since version 12.3), RHEL (since RHEL 7), CentOS (since CentOS 7[50]) and Ubuntu (since version 12.04.2).[51] As of January 2017, FreeBSD support is in a planning stage

In August 2016 it was reported that two security researchers had found the "golden key" security key Microsoft uses in signing operating systems.[112] Technically, no key was exposed, however, an exploitable binary signed by the key was. This allows any software to run as though it was genuinely signed by Microsoft and exposes the possibility of rootkit and bootkit attacks. This also makes patching the fault impossible, since any patch can be replaced (downgraded) by the (signed) exploitable binary. Microsoft responded in a statement that the vulnerability only exists in ARM architecture and Windows RT devices, and has released two patches, however, the patches do not (can not) remove the vulnerability, which would require key replacements in end user firmware to fix.

Από wikipedia

κατατοπιστικότατος

[manosdoc]

Γνωρίζει κανείς αν ο τρόπος που το Ubuntu κάνει rendering τα fonts με κάποιο patch (υπό πατέντα) στο freetype2 έχει έρθει πλέον και για τις υπόλοιπες διανομές και δη για Fedora;
Υποτίθεται πως από την έκδοση 2.8 και μετά το φτάσανε σε parity με open-source κώδικα.

- - - Updated - - -

Με τον τελευταίο Chrome dev βλέπω γίνονται σωστά respect τα buttons του θέματος του GNOME!
Άρα σύντομα και στον Chromium!

[manosdoc]

Πλέον έχουμε και AAC codecs στα επίσημα repo
sudo dnf install fdk-aac

[manosdoc]

Μένουν 5 μέρες για την επίσημη της Fedora 27 και τα RCs iso είναι ήδη έτοιμα
https://dl.fedoraproject.org/pub/alt...on/x86_64/iso/

Κατά τα άλλα στην Rawhide έχουμε 3.27 gnome shell από σήμερα, χωρίς να προλάβω να δω διαφορές.

[manosdoc]

Τελικά πηγαίνει για 14 Νοέμβρη η Fedora 27.
https://lists.fedoraproject.org/arch...TU6YX3KGT2BD2/

Πάντως η Rawhide πάει νερό.

[pmav99]

Αν κάποιος με rawhide χρησιμοποιούσε παλιότερα Arch και μπορεί να κάνει μια σύγκριση θα είχε νομίζω κάποιο ενδιαφέρον

[mzaf]

Τελικά πηγαίνει για 14 Νοέμβρη η Fedora 27.
https://lists.fedoraproject.org/arch...TU6YX3KGT2BD2/

Πάντως η Rawhide πάει νερό.

Rawhide????Ποιος το σκέφτηκε το όνομα?
Μου ήρθε στο μυαλό αυτό:
https://www.youtube.com/watch?v=qCRae5mRoRE

[imitheos]

Rawhide????Ποιος το σκέφτηκε το όνομα?
Μου ήρθε στο μυαλό αυτό:
https://www.youtube.com/watch?v=qCRae5mRoRE

Όσο να ναι είναι καλύτερο όνομα από το openSUSE Tumbleweed που είναι εκείνο το πράμα που κυλάει στην έρημο στα παλιά γουέστερν

[mzaf]

Όσο να ναι είναι καλύτερο όνομα από το openSUSE Tumbleweed που είναι εκείνο το πράμα που κυλάει στην έρημο στα παλιά γουέστερν

[manosdoc]

Αν κάποιος με rawhide χρησιμοποιούσε παλιότερα Arch και μπορεί να κάνει μια σύγκριση θα είχε νομίζω κάποιο ενδιαφέρον

Σίγουρα έχω και ένα Ubuntu 17.10 για failsafe μιας και δεν είμαι έμπειρος χρήστης για να λύνω προβλήματα εξαρτήσεων πέρα από τα τις απλές λύσεις.
Παρόλα αυτά συμπεριφέρεται άψογα για developmental packages.
Ας πούμε μόλις μου ήρθε το Libreoffice 6.0!
Εγώ που το έχω για απλή χρήση δεν μου έχει κάνει καθόλου νερά. Βέβαια να πω όταν το πρωτοέστησα το έστησα με Netinstall image (Everything boot iso).
Έβαλα και rawhide σε έναν θείο μου που θέλει τα τελείως βασικά. Αν πάει καλά το πράγμα θα αναφέρω ατάκες. Αν όχι, θα τα ακούσω εγώ :P

[imitheos]

Αν κάποιος με rawhide χρησιμοποιούσε παλιότερα Arch και μπορεί να κάνει μια σύγκριση θα είχε νομίζω κάποιο ενδιαφέρον

Παρόλα αυτά συμπεριφέρεται άψογα για developmental packages.
Ας πούμε μόλις μου ήρθε το Libreoffice 6.0!
Εγώ που το έχω για απλή χρήση δεν μου έχει κάνει καθόλου νερά. Βέβαια να πω όταν το πρωτοέστησα το έστησα με Netinstall image (Everything boot iso).
Έβαλα και rawhide σε έναν θείο μου που θέλει τα τελείως βασικά. Αν πάει καλά το πράγμα θα αναφέρω ατάκες. Αν όχι, θα τα ακούσω εγώ :P

Δεν ξέρω κατά πόσο μπορεί να είναι αντικειμενική μια τέτοια σύγκριση. Λογικά θα είναι ανέκδοτη-αστήρικτη πληροφορία με την εμπειρία του καθενός. Για αυτή την εμπειρία, σημαντικό ρόλο παίζουν α) ποια πακέτα έχει εγκαταστήσει, β) πότε και για πόσο καιρό δοκίμασε την κάθε διανομή. Μου έχει τύχει μερικές φορές να γ..θεί ο Δίας και εγώ να προσπέρασα το πρόβλημα απλά επειδή είχα δουλειά και δεν έκανα update εκείνη την ημέρα.

Από εκεί και πέρα, το αποτέλεσμα είναι σε γενικές γραμμές πάρα πολύ καλό με το σύστημα να σπάει σπάνια. Αν μιλάμε για το κλασικό Desktop, Workstation σενάριο χωρίς "εξωτικά" πακέτα, τότε δεν θα έχεις θέματα. Ξέρω κόσμο που πέρασε σε rawhide γιατί σιχάθηκε τα πολλά προβλήματα που αντιμετώπιζε στην αναβάθμιση από F-Χ σε F-(X+1) και το δουλεύει καιρό χωρίς κανένα πρόβλημα. Το Rawhide (καθώς και το openSUSE Tumbleweed) χρησιμοποιούν την υποδομή OpenQA οπότε το snapshot κάθε ημέρας δοκιμάζεται σε διάφορα σενάρια και έτσι δεν σπάει τόσο εύκολα. Εδώ μπορείς να δεις για παράδειγμα το αποτέλεσμα της χτεσινής snapshot και ποια τεστ απέτυχαν. Άκυρο. Έδωσα λάθος URL. Το παραπάνω url ήταν για το Fedora 27. Το rawhide (περισσότερα failed tests) μπορείς να το δεις εδώ.

Ακόμη και έτσι όμως, αραιά και που σίγουρα θα ξεφύγει κάτι και θα χρειαστεί να το πειράξεις. Πχ (στο Tumbleweed) έτυχε πριν καιρό ένα πρόβλημα στον πυρήνα και ο radeon με τον amdgpu μάλωναν για το ποιος θα φορτωθεί (σε κάρτες GCN γενιάς για τις οποίες υπάρχει υποστήριξη και στους δύο οδηγούς). Αυτό οδήγησε σε μπάλα load τον ένα - load τον άλλον μέχρι να φάνε όλη την μνήμη και να κρασάρει το μηχάνημα. Αυτό δεν θα μπορούσε να το πιάσει η OpenQA. Όσοι χρήστες δεν είχαν τα συγκεκριμένα 10-15 μοντέλα ή όσοι ήμασταν δεινόσαυροι και μάθαμε να ορίζουμε χειροκίνητα κάποιον οδηγό σε κάποιο αρχείο στον xorg.conf.d, το γλυτώσαμε το πρόβλημα.