Το thread του Debian (v.7)

[famous-walker]

@imitheos Το wine prefix ομως ειναι 64bit, σωστα; Η αληθεια ειναι πως ολα τρεχουν σε 64bit prefix, αλλα καποια, κυριως τα παλιοτερα, εχουν καλυτερη συμβατοτητα με 32bit. Να πω την αληθεια δεν το εχω εντοπισει γιατι, ισως εχει να κανει με extra components. Το winetricks πχ, σε ειδοποιει οτι μπορει να υπαρξουν καποιες δυσλειτουργιες οταν εγκαθιστας καποια προσθετα σε 64bit.

Βεβαια οσο βελτιωνεται η εφαρμογη και μειωνονται οι αναγκες για tweaking και workarounds, τοσο λιγοτερο απαραιτητο γινεται και το 32bit. Αυτο ας πουμε (bug #9127) ηταν ενα γνωστο προβλημα που υπηρχε για παρα πολλα χρονια και λυθηκε πριν απο ενα μηνα (κυριως λογω patent expiration). Ως workaround ηταν η εγκατασταση των lavfilters. Ε σε 64bit δεν επαιζε με τιποτα παροτι γινοταν χωρις προβλημα η εγκατασταση και ενω το παιχνιδι κατα τα αλλα ετρεχε κανονικα.

Παντως το wine εχει κανει πραγματικα τεραστια βηματα. Εκει που αν επαιζε κατι ησουν τυχερος, πλεον αν δεν παιζει κατι εισαι μαλλον ατυχος.

[imitheos]

@imitheos Το wine prefix ομως ειναι 64bit, σωστα;

Και το "κανονικό" wine, από τη μάνα του δημιουργεί 64bitο prefix αν δεν ορίσεις το WINEARCH πριν τρέξεις κάποια εντολή. Έχεις δίκιο όμως ότι έπρεπε να το αναφέρω και αυτό αλλά δεν το θυμήθηκα καθόλου. Δεν το θυμάμαι στα σίγουρα αλλά έχω την εντύπωση ότι το wine που έχει χτιστεί με αυτόν τον τρόπο μπορεί να δουλέψει μόνο με 64bit prefixes. Αν κάποιος δηλαδή έχει παλιά 32bit prefixes με προγράμματα, θα πρέπει να ξανα-εγκατασταθούν από την αρχή. Ένας λοιπόν από τους λόγους που δεν τον χτίζουν έτσι οι διανομές θα είναι σίγουρα και αυτός.

Το winetricks πχ, σε ειδοποιει οτι μπορει να υπαρξουν καποιες δυσλειτουργιες οταν εγκαθιστας καποια προσθετα σε 64bit.

Έχεις δίκιο και σε αυτό. Αυτό όμως και πάλι ισχύει σε όλα τα 64bit prefixes και με multilib. Αν δεν έχεις κάποιο παλιό 32bit prefix ή αν δεν έχεις ορίσει globally κάπου την WINEARCH για να δημιουργείς 32bit prefixes, θα το βρεις μπροστά σου όταν πας να κάνεις κάτι πολύπλοκο (ακόμη και το .NET, που δεν το λες κάτι niche, από μία έκδοση και μετά δεν εγκαθίσταται σωστά σε 64bit. Κάθε φορα που το χρειάζομαι προσπαθώ να θυμηθώ πώς στο καλό το είχα εγκαταστήσει για να δουλεύει. Θέλει χειροκίνητη μανούρα).

Δυσλειτουργίες ειδικά για τον non-multilib τρόπο χτισίματος υπάρχουν αλλά είναι πιο πολύ ότι τα διάφορα εργαλεία, όπως πχ το winetricks που ανέφερες, δεν έχουν "ενημερωθεί" ώστε να έχουν πρόνοια για αυτόν (ίσως ακριβώς επειδή δεν χρησιμοποιείται ευρέως αυτός ο τρόπος). Για παράδειγμα, το dxvk έρχεται με ένα script που κρίνει ποια αρχεία θα εγκαταστήσει ελέγχοντας την ύπαρξη των καταλόγων system32, syswow64. Αυτό στην περίπτωση του non-multilib δεν λειτουργεί σωστά και αντιγράφει 32bit αρχεία στον κατάλογο των 64bit.

Ακόμη υπάρχουν κάποια "rough edges" φυσικά αλλά πιστεύω στο μέλλον θα δουλεύει τέλεια και όλοι θα γυρίσουν σε αυτόν τον τρόπο. Εγώ το έγραψα και σαν ενημέρωση για κάποιον που χτίζει μόνος του τον wine να το ξέρει αλλά ποιο πολύ σαν καθησυχασμό για το θέμα του "παέι το i386". Wine, steam, κτλ καλύπονται από το multilib. Παλαιά proprietary binary προγράμματα μπορούν να χρησιμοποιηθούν σε chroot / vm / κτλ παλαιάς έκδοσης. Οπότε το πρόβλημα είναι τα 32bit tablets , netbooks, κτλ.

[famous-walker]

Και το "κανονικό" wine, από τη μάνα του δημιουργεί 64bitο prefix αν δεν ορίσεις το WINEARCH πριν τρέξεις κάποια εντολή. Έχεις δίκιο όμως ότι έπρεπε να το αναφέρω και αυτό αλλά δεν το θυμήθηκα καθόλου. Δεν το θυμάμαι στα σίγουρα αλλά έχω την εντύπωση ότι το wine που έχει χτιστεί με αυτόν τον τρόπο μπορεί να δουλέψει μόνο με 64bit prefixes. Αν κάποιος δηλαδή έχει παλιά 32bit prefixes με προγράμματα, θα πρέπει να ξανα-εγκατασταθούν από την αρχή. Ένας λοιπόν από τους λόγους που δεν τον χτίζουν έτσι οι διανομές θα είναι σίγουρα και αυτός.


Έχεις δίκιο και σε αυτό. Αυτό όμως και πάλι ισχύει σε όλα τα 64bit prefixes και με multilib. Αν δεν έχεις κάποιο παλιό 32bit prefix ή αν δεν έχεις ορίσει globally κάπου την WINEARCH για να δημιουργείς 32bit prefixes, θα το βρεις μπροστά σου όταν πας να κάνεις κάτι πολύπλοκο (ακόμη και το .NET, που δεν το λες κάτι niche, από μία έκδοση και μετά δεν εγκαθίσταται σωστά σε 64bit. Κάθε φορα που το χρειάζομαι προσπαθώ να θυμηθώ πώς στο καλό το είχα εγκαταστήσει για να δουλεύει. Θέλει χειροκίνητη μανούρα).

Ναι πολυ σωστα. Οντως απο default φτιαχνει 64μπιτο. Αν θες 32, πρεπει να το κανεις χειροκινητα και να οριζεις μετα με ποιο θα ανοιξει η καθε εφαρμογη. Απλα αν για διαφορους λογους εχεις πολλα prefixes, η διαχειριση γινεται πολυπλοκη. Υπαρχουν βεβαια διαφοροι managers (οπως το bottles) που απλοποιουν την διαδικασια δημιουργιας και διαχειρισης prefix, ενω εχουν και διαφορους installers για γνωστες και αγνωστες εφαρμογες. Και εγω για τα (λιγα) παιχνιδια που δοκιμαζω κατα καιρους χρησιμοποιω το lutris, το οποιο και το προτιμω απο το bottles γιατι ενω απλοποιει την διαχειριση και παλι εχεις τον ελεγχο. Υποστηριζει και gamescope οποτε μπορεις να εχεις και upscaling σε παλια παιχνιδια πιο ευκολα απο το να τα ετρεχες σε windows που και εκει μπορει να ψαχνοσουν με συμβατοτητες.

Φυσικα οσο βελτιωνεται και τρεχει τα παντα τοσο λιγοτερη αναγκη υπαρχει για prefixes και διαχειριστες.

Δυσλειτουργίες ειδικά για τον non-multilib τρόπο χτισίματος υπάρχουν αλλά είναι πιο πολύ ότι τα διάφορα εργαλεία, όπως πχ το winetricks που ανέφερες, δεν έχουν "ενημερωθεί" ώστε να έχουν πρόνοια για αυτόν (ίσως ακριβώς επειδή δεν χρησιμοποιείται ευρέως αυτός ο τρόπος). Για παράδειγμα, το dxvk έρχεται με ένα script που κρίνει ποια αρχεία θα εγκαταστήσει ελέγχοντας την ύπαρξη των καταλόγων system32, syswow64. Αυτό στην περίπτωση του non-multilib δεν λειτουργεί σωστά και αντιγράφει 32bit αρχεία στον κατάλογο των 64bit.

Ακόμη υπάρχουν κάποια "rough edges" φυσικά αλλά πιστεύω στο μέλλον θα δουλεύει τέλεια και όλοι θα γυρίσουν σε αυτόν τον τρόπο. Εγώ το έγραψα και σαν ενημέρωση για κάποιον που χτίζει μόνος του τον wine να το ξέρει αλλά ποιο πολύ σαν καθησυχασμό για το θέμα του "παέι το i386". Wine, steam, κτλ καλύπονται από το multilib. Παλαιά proprietary binary προγράμματα μπορούν να χρησιμοποιηθούν σε chroot / vm / κτλ παλαιάς έκδοσης. Οπότε το πρόβλημα είναι τα 32bit tablets , netbooks, κτλ.

Ναι εχεις δικιο, και εγω δεν βλεπω καποιο θεμα να δημιουργειται για το multilib. Αυτο με το dxvk πολυ ενδιαφερον, δεν το ηξερα. Μπορει και η microsoft καποια στιγμη να ενσωματωσει το wine για υποστηριξη παλιοτερων εφαρμογων ωστε να γλυτωνει και λεφτα απο το development backwards-compatibility. Για το office που τους καιει εχουν τροπους φαινεται να το αποτρεπουν απο το να τρεχει σε wine.

[jim_p]

Επιτελους 6.6.x στο unstable.
https://tracker.debian.org/news/1489...into-unstable/

[Slammer]

Επιτελους 6.6.x στο unstable.
https://tracker.debian.org/news/1489...into-unstable/

εχει κάτι σημαντικό ο νεος πυρηνας? Μόλις πέρασε στο laptop μου....

[jim_p]

Το μονο σημαντικο που θυμαμαι ειναι ενα προβλημα με το wifi που φτιαχτηκε στον 6.6.6 ή 6.6.7. Αυτο αν χρησιμοποιεις wifi με το λαπτοπ σου. Μετα απο αυτο, ειναι ο lts αυτης της χρονιας, αλλα το debian δεν πακεταρει lts αν δεν προοριζονται για την επομενη stable, οποτε θα αντικατασταθει απο τον 6.7 τον αλλο μηνα. Τελος, παμε σε 6.6 γιατι ο 6.5 εγινε eol τελη Νοεμβριου, οποτε δεν παιρνει πια bug fixes και security updates.

Για το φιλο Jojos να πω πως ο nvidia 340 ειναι πατσαρισμενος για τον 6.6 εδω και ~40 μερες και θα εγκατασταθει χωρις προβλημα.

[jim_p]

Perl 5.38 transition underway
https://lists.debian.org/debian-deve.../msg00000.html

Με το μαλακο τα dist-upgrades.

[jim_p]

Νωριτερα θελησα να κατεβασω κατι στο rpi που τρεχει debian 11 arm64 και επεσα πανω στο προβλημα που λεει ο τυπος εδω
https://unix.stackexchange.com/quest...errors-in-kali

Εχω κατεβασει δεκαδες, αν οχι εκατονταδες πραγματα με wget στο συγκεκριμενο συστημα, αλλα ηταν η πρωτη φορα που πεταχτηκε κατι τετοιο. Το ca-certificates ηταν ηδη εγκατεστημενο, προφανως σε μια εκδοση του 2021, και δεν υπαρχει κατι νεοτερο στο backports. Τι γινεται σε αυτη την περιπτωση? Απλα παιρνω το ρισκο και το κατεβαζω με την παραμετρο που λεει?

[imitheos]

Τι γινεται σε αυτη την περιπτωση? Απλα παιρνω το ρισκο και το κατεβαζω με την παραμετρο που λεει?

1) Ναι με κίνδυνο να κατεβάσεις κάτι από αμφίβολο site.
2) Κατεβάζεις το νεώτερο πακέτο από το 12 / unstable, το αποσυμπιέζεις στο /tmp, παίρνεις τον κατάλογο /tmp/τάδε/usr/share/ca-certificates και τον πετάς στο /usr/local/share (ώστε να έχεις /usr/local/share/ca-certificates/blahblah), τρέχεις update-ca-certificates με κίνδυνο να σπάσει κάτι (τα certificates επεξεργάζονται με το openssl οπότε υπάρχει ένας πάρα-πάρα-πολύ-μικρός κίνδυνος τα νεώτερα certficiates να έχουν μορφή που να μην καταλαβαίνει το openssl του 11 αν και δεν το νομίζω)
3) Αναβαθμίζεις τα πάντα στο 12.

[jim_p]

Για το 3 ελεγα, αλλα βαριεμαι να κανω εγκατασταση και σεταρισμα απο την αρχη. Να ρισκαρω in place upgrade? Εχω ακουσει οτι σε debian παει καλα :P

Το 2 σιγουρα δεν θα το καταφερω μονος μου.

[imitheos]

Κάθε λύση έχει ένα άλφα κίνδυνο διαφορετικό σε κάθε μία.

Για το 3 ελεγα, αλλα βαριεμαι να κανω εγκατασταση και σεταρισμα απο την αρχη. Να ρισκαρω in place upgrade? Εχω ακουσει οτι σε debian παει καλα :P

Δεν γνωρίζω αν η arm αρχιτεκτονική έχει ιδιαιτερότητες (όπως πχ είχαμε παλιά σε sparc, mips, κτλ) αλλά σε x86 δεν μου έχει τύχει κάτι καταστροφικό ποτέ από in-place-upgrade σε καμμία διανομή (εντάξει σε fedora μου έχουν τύχει μ..κίες).

Το 2 σιγουρα δεν θα το καταφερω μονος μου.

Γιατί;

# cd /tmp 
# wget http://ftp.de.debian.org/debian/pool/main/c/ca-certificates/ca-certificates_20230311_all.deb  
# dpkg-deb -x ca-certificates_20230311_all.deb kk

# mkdir -p /usr/local/share/ca-certificates 
# mv /tmp/kk/usr/share/ca-certificates/* /usr/local/share/ca-certificates/
# /usr/sbin/update-ca-certificates (βλέπεις αν βγάλει κάποιο error ή απλά λέει replacing τάδε certificate)

[billy]

Παιρνεις το root/intermediate cert που σου λείπει απο το συγκεκριμένο site (εαν είναι αυτό το πρόβλημα) το βάζεις στο /etc/ssl/certs και τρέχεις update-ca-certificates

[jim_p]

Επειδη δεν εχουμε θεμα αποκλειστικα για εφαρμογες, το γραφω εδω μιας και το πετυχα στο r/debian.
Το viber λοιπον, που εινια απο τις εφαρμογες που μισω αλλα αναγκαζομια να χρησιμοποιω, αλλαξε απο gstreamer σε ffmpeg με την προχτεσινη MINOR ενημερωση του. Και προφανως οχι το latest ffmpeg, το ffmpeg 4.x που πλεον ειναι αρχαιο, γιαυτο και υπαρχει στο oldstable.

https://old.reddit.com/r/debian/comm..._on_debian_12/

Αν το βαλει καποιος και δεν θελει να βαλει το repo του oldstable για 2 βιβλιοθηκες μονο, να πω πως ο Marillat το εχει στο dmo (για stable, testing και unstable) ακομα επειδη χτιζει το kodi 20 με αυτο. Το εχει σαν minimum εξαρτηση το kodi απο upstream, αλλα δεν θελει να το πατσαρει ωστε να χτιζεται με νεοτερο ffmpeg, γιαυτο το kodi εχει γινει για μενα ενα κακο πακετο του dmo.

- - - Updated - - -

cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

Τι ειναι παλι αυτο? Μου το εβγαλε μολις τωρα μετα τη σημερινη ενημερωση στο testing, αμεσως μετα το update του initramfs. Ενημερωθηκαν τα πακετα

Start-Date: 2024-01-18  06:40:28
Commandline: apt-get upgrade
Upgrade: acl:amd64 (2.3.1-4, 2.3.1-6), libacl1:amd64 (2.3.1-4, 2.3.1-6), kbd:amd64 (2.5.1-1+b1, 2.6.4-2), libfuse3-3:amd64 (3.14.0-4, 3.14.0-5), inetutils-telnet:amd64 (2:2.5-1, 2:2.5-3), fuse3:amd64 (3.14.0-4, 3.14.0-5), python3-lazy-object-proxy:amd64 (1.9.0-1+b1, 1.10.0-1), libuv1:amd64 (1.46.0-2, 1.46.0-3)
End-Date: 2024-01-18  06:40:47

[imitheos]

cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

Τι ειναι παλι αυτο? Μου το εβγαλε μολις τωρα μετα τη σημερινη ενημερωση στο testing, αμεσως μετα το update του initramfs. Ενημερωθηκαν τα πακετα

Τρέξε "alias cp" και δες τι επιστρέφει. Μήπως, όπως είχες το -c στο wget, έβαλες το -n στο cp για να μην σβήνει τα αρχεία;

[jim_p]

Το cp το εχω κανει alias σε cp -v για να ξερω τι αντιγραφω. Αυτο λεει και οταν το τρεξω. Αλλα το παραπανω ειναι του root υποτιθεται και εινια απο καποιο σκριπτακι που το τρεχει. Λογικα θα ειναι απο αυτο
https://bugs.debian.org/cgi-bin/bugr...gi?bug=1059936