«Περίεργη» συμπεριφορά xinitrc με «χειροκινητα» sessions
#41
debianass, post: 28314, member: 1803 είπε κι ελάλησε:@DarkGoth

Μιλάω για νέα εγκατάσταση debian stretch 64bit με το δικό του gnome και kernel. Τη δοκιμή την έκανα σε παλιότερη εγκατάσταση (από όταν ήταν σε testing η stretch) με το openbox κι όλα τα καλούδια του minimal desktop (customized openbox) του sparky με τοπικά μεταγλωττισμένο kernel. Δηλαδή αρκετά πειραγμένο/προσαρμοσμένο debian.

νεα εγκατασταση debian 9 με τα δικα του επανω, ειχα δοκιμασει στον εξομοιωτη. το gnome εγκατασταθηκε κανονικοτατα και δουλευε μια χαρα (με την tasksel προεπιλεγμενη εγκατασταση gnome γραφικου. οχι custom γυμνη, οπως εχω κανει στο βασικο μου συστημα και στον κλωνο). δεν ξερω βεβαια αν ηταν σε wayland, γιατι δεν το κρατησα καθολου. ειδα οτι κανει εγκατασταση, ειδα 2-3 πολυ βασικα επιφανειακα πραγματακια, και το πεταξα, γιατι δεν ειχα τι να το κανω (αφου εχω τον κλωνο)
ονομαζομαι DarkGoth, και ειμαι «καλα»( ; )... το OsArena με θεραπευσε... (goth=!ok {equals} EMO)...  Emo
  Απάντηση
#42
@debianass

Το Debian είναι καλό για server αλλά σε κάποιες περιπτώσεις είναι κακό για desktop (με τη γενική έννοια του όρου). Όπως και το CentOS αντίστοιχα. Ναι, ξέρω ότι εσύ και πολλοί άλλοι το χρησιμοποιείτε έτσι κι ενδεχομένως σας καλύπτει, ισχύει όμως. Θέλεις λόγου χάρη να χρησιμοποιήσεις το τάδε DE. Βάζεις την τελευταία έκδοση του Debian και με το καλημέρα είσαι 2-3 εκδόσεις πίσω από την τρέχουσα του DE αυτού. Δε μπορείς να συμβαδίσεις, λόγω της πολιτικής (μη) αναβάθμισης και σε σημεία το DE σου δε θα έχει κάνει καν καθαρή μετάβαση από την προηγούμενη έκδοσή του αλλά θα έχεις κατάλοιπά της, με ό,τι συνεπάγεται αυτό για τη λειτουργικότητα. Αυτό είναι κάτι που συμβαίνει ξανά και ξανά, με αποτέλεσμα ορισμένοι DE developers να συστήνουν να αποφεύγεται το Debian. Και είναι κάτι που το κληρονομούν και τα παράγωγα.

Τώρα, μπορεί κάποιος να πει «δεν έχω πρόβλημα που το DE είναι 2 εκδόσεις πίσω, ούτε με πειράζει που δε θα αναβαθμιστεί για χρόνια». Σε αυτή την περίπτωση όμως, μετατρέπει ένα μειονέκτημα της διανομής σε «μη μειονέκτημα», όπως κάνουμε όλοι λίγο-πολύ. Όμως αυτό δεν εξαλείφεται. Και το θέμα δεν είναι το να έχεις την τελευταία έκδοση του οτιδήποτε έτσι, για το γαμώτο. Ίσως σου φανεί περίεργο (αν και δεν το πιστεύω) αλλά η πολιτική του Debian με τις αναβαθμίσεις έχει αποδειχθεί ότι κατά καιρούς (ευτυχώς όχι συχνά) το αφήνει εκτεθειμένο. Είτε γιατί καθυστερεί υπερβολικά να κλείσει τις τρύπες είτε γιατί απλά δε μπορεί. Αυτό που λες, ότι «δουλεύει και δεν το πειράζουμε», ενίοτε οδηγεί σε καταστάσεις παρόμοιες με τα XP (εννοώ τις κακές καταστάσεις που γνωρίζουμε όλοι). Και ούτε τα backports σώζουν την κατάσταση, γιατί υπάρχουν περιπτώσεις όπου είναι τεχνικά αδύνατο να γίνει κάτι backport.

Όσο για τα στερεότυπα και όλα αυτά, πάντα θα υπάρχουν. Εγώ όμως αναφερόμουν περισσότερο στη νοοτροπία «έτσι κάναμε το τάδε τότε, έτσι το μάθαμε, έτσι το συνεχίζουμε και σήμερα». Π.χ. μια διαδικασία ανάπτυξης που ίσως ήταν αποδοτική το 1998, δεν είναι απαραίτητα το ίδιο αποδοτική το 2017. Αυτό το εντοπίζεις και προσαρμόζεσαι ή επιμένεις στον τρόπο σου μέχρι που θα σε αφήσουν πίσω οι καιροί.
Το άπλυτο κορμί το πλένεις. Καθαρίζει. Η βρόμικη ψυχή πώς πλένεται;
  Απάντηση
#43
DarkGoth, post: 28313, member: 1051 είπε κι ελάλησε:πεταει κατι xinit, κατι xorg modules, κατι τετοια, και την ακουει
Ντάρκη, τι πράγματα είναι αυτά; Να μας δείξεις αυτά που πετάει, να το ψάξουμε όλοι μαζί. Μήπως όμως σκαλώνει η αναβάθμιση από 8 σε 9 λόγω VM;

Πάντως, για το xinitrc, εφόσον έχεις το gnome-session, θα έπρεπε να σε ξεκινάει σε Xorg. Το Wayland κανονικά δεν το βλέπει καν το xinitrc, οπότε αν όντως σε ξεκινάει έτσι, κοίτα κάπου μέσα στο Xsession ή ό,τι άλλο έχει το Debian.
Το άπλυτο κορμί το πλένεις. Καθαρίζει. Η βρόμικη ψυχή πώς πλένεται;
  Απάντηση
#44
Soulrain Falls, post: 28317, member: 1313 είπε κι ελάλησε:Ντάρκη, τι πράγματα είναι αυτά; Να μας δείξεις αυτά που πετάει, να το ψάξουμε όλοι μαζί. Μήπως όμως σκαλώνει η αναβάθμιση από 8 σε 9 λόγω VM;

Πάντως, για το xinitrc, εφόσον έχεις το gnome-session, θα έπρεπε να σε ξεκινάει σε Xorg. Το Wayland κανονικά δεν το βλέπει καν το xinitrc, οπότε αν όντως σε ξεκινάει έτσι, κοίτα κάπου μέσα στο Xsession ή ό,τι άλλο έχει το Debian.

ειναι τα διαφορα που εχει ο Χ (εκτος του γραφικου περιβαλλοντος). xinit, xserver, xorg, xinput, οι διαφοροι drivers γραφικων του xserver (nouveau, vesa, κλπ). τα πεταει ΟΛΑ. δεν αφηνει τιποτα μεσα. και ακομα και αν τα ξαναεγκαταστησω, δεν επανερχεται. το xsession δεν το χρησιμοποιω στο xinitrc, αλλα λες το wayland να το τρεχει απο προεπιλογη; xsession στο home δεν εχω. υπαρχει μονο το systemwide xsession, το οποιο το εχω ανοιξει (αλλα οπως ειπα και πριν, δεν το χρησιμοποιω), αλλα δεν εχω καταλαβει και πολλα απο δαυτο:...

Κώδικας:
#!/bin/sh
#
# /etc/X11/Xsession
#
# global Xsession file -- used by display managers and xinit (startx)

# $Id: Xsession 967 2005-12-27 07:20:55Z dnusinow $

set -e

PROGNAME=Xsession

message () {
  # pretty-print messages of arbitrary length; use xmessage if it
  # is available and $DISPLAY is set
  MESSAGE="$PROGNAME: $*"
  echo "$MESSAGE" | fold -s -w ${COLUMNS:-80} >&2
  if [ -n "$DISPLAY" ] && which xmessage > /dev/null 2>&1; then
    echo "$MESSAGE" | fold -s -w ${COLUMNS:-80} | xmessage -center -file -
  fi
}

message_nonl () {
  # pretty-print messages of arbitrary length (no trailing newline); use
  # xmessage if it is available and $DISPLAY is set
  MESSAGE="$PROGNAME: $*"
  echo -n "$MESSAGE" | fold -s -w ${COLUMNS:-80} >&2;
  if [ -n "$DISPLAY" ] && which xmessage > /dev/null 2>&1; then
    echo -n "$MESSAGE" | fold -s -w ${COLUMNS:-80} | xmessage -center -file -
  fi
}

errormsg () {
  # exit script with error
  message "$*"
  exit 1
}

internal_errormsg () {
  # exit script with error; essentially a "THIS SHOULD NEVER HAPPEN" message
  # One big call to message() for the sake of xmessage; if we had two then
  # the user would have dismissed the error we want reported before seeing the
  # request to report it.
  errormsg "$*" \
           "Please report the installed version of the \"x11-common\"" \
           "package and the complete text of this error message to" \
           "<debian-x@lists.debian.org>."
}

# initialize variables for use by all session scripts

OPTIONFILE=/etc/X11/Xsession.options

SYSRESOURCES=/etc/X11/Xresources
USRRESOURCES=$HOME/.Xresources

SYSSESSIONDIR=/etc/X11/Xsession.d
USERXSESSION=$HOME/.xsession
USERXSESSIONRC=$HOME/.xsessionrc
ALTUSERXSESSION=$HOME/.Xsession
ERRFILE=$HOME/.xsession-errors

# attempt to create an error file; abort if we cannot
if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] &&
  [ ! -L "$ERRFILE" ]; then
  chmod 600 "$ERRFILE"
elif ERRFILE=$(tempfile 2> /dev/null); then
  if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-$USER"; then
    message "warning: unable to symlink \"$TMPDIR/xsession-$USER\" to" \
             "\"$ERRFILE\"; look for session log/errors in" \
             "\"$TMPDIR/xsession-$USER\"."
  fi
else
  errormsg "unable to create X session log/error file; aborting."
fi

exec >>"$ERRFILE" 2>&1

echo "$PROGNAME: X session started for $LOGNAME at $(date)"

# sanity check; is our session script directory present?
if [ ! -d "$SYSSESSIONDIR" ]; then
  errormsg "no \"$SYSSESSIONDIR\" directory found; aborting."
fi

# Attempt to create a file of non-zero length in /tmp; a full filesystem can
# cause mysterious X session failures.  We do not use touch, :, or test -w
# because they won't actually create a file with contents.  We also let standard
# error from tempfile and echo go to the error file to aid the user in
# determining what went wrong.
WRITE_TEST=$(tempfile)
if ! echo "*" >>"$WRITE_TEST"; then
  message "warning: unable to write to ${WRITE_TEST%/*}; X session may exit" \
          "with an error"
fi
rm -f "$WRITE_TEST"

# use run-parts to source every file in the session directory; we source
# instead of executing so that the variables and functions defined above
# are available to the scripts, and so that they can pass variables to each
# other
SESSIONFILES=$(run-parts --list $SYSSESSIONDIR)
if [ -n "$SESSIONFILES" ]; then
  set +e
  for SESSIONFILE in $SESSIONFILES; do
    . $SESSIONFILE
  done
  set -e
fi

exit 0

# vim:set ai et sts=2 sw=2 tw=80:

κατι αλλο δεν υπαρχει, οσο το εχω ψαξει
ονομαζομαι DarkGoth, και ειμαι «καλα»( ; )... το OsArena με θεραπευσε... (goth=!ok {equals} EMO)...  Emo
  Απάντηση
#45
Πιθανότατα από το πολύ ξεγύμνωμα αφαίρεσες κάτι και έκανες τον X soft dependency (ή όπως αλλιώς το αποκαλεί το Debian). Βέβαια, στην ψαχτική μου βρισκω αναφορές για το ίδιο ακριβώς πρόβλημα από το 2010 μέχρι το 2015, οπότε κάπου τα έχουν σκατώσει με το πακετάρισμα. Έχει τρόπο το apt για να του πεις ότι το τάδε πακέτο το εγκατέστησες επειδή το ήθελες και δεν είναι εξάρτηση κάποιου άλλου, σωστά; Κάνε αυτό για να μη σου τα πετάει.

Το Xsession το ανέφερα περισσότερο ως παράδειγμα γιατί, εφόσον έχεις εγκατεστημένο τον X και δηλώνεις στο xinitrc το gnome-session, θα έπρεπε να ξεκινάει σε X. Αφού σε βάζει σε Wayland, κάπου είναι δηλωμένο αυτό. Αν είχες τον GDM π.χ., η σχετική ρύθμιση είναι στα αρχεία του. Δεν τον έχεις όμως, άρα κάπου αλλού είναι.

Στο μεταξύ, αν σου ξεκινάει τουλάχιστον ένα tty, ρίξε ένα
Κώδικας:
echo $XDG_SESSION_TYPE
για να βεβαιωθείς ότι όντως δεν είσαι σε X.
Το άπλυτο κορμί το πλένεις. Καθαρίζει. Η βρόμικη ψυχή πώς πλένεται;
  Απάντηση
#46
το ειχα δοκιμασει να τα «κλειδωσω» (οχι ακριβως κλειδωμα, αλλα παρακαμψη. δεν εχει κλειδωμα, η, ισως εγω δεν το εχω βρει), αλλα τοτε δεν προχωρουσε καν στο upgrade. ελεγε οτι πρεπει να αφαιρεθουν οπωσδηποτε, και εκανε abort. αν το αφηνα να τα πεταξει, εκανε το upgrade κανονικα (δεν ανεφερε καποιο σφαλμα πουθενα), αλλα στην επανεκκινηση η οθονη εμενε σε terminal και αναβοσβηνε (ναι, καλα ειδες, αναβοσβηνε), λες και ειχε παθει επιληψια. τελικα το παρατησα και ουτε ξανασχοληθηκα (γιατι επαιρνε και αρκετες ωρες η ολη διαδικασια).

το «καλο» στην ολη υποθεση, ειναι, οτι αν κανω μερικο upgrade (οχι δηλαδη dist-upgrade, αλλα σκετο upgrade, που κανει upgarde μονο οτι μπορει να γινει, χωρις να πεταχτουν πραγματα), το κανει κανονικοτατα και ολα λειτουργουν μια χαρα. αλλα δεν ξερω ποσο μπορει να αντεξει σε μερικο upgrade. καποια στιγμη οι νεες εκδοσεις προγραμματων (η, μικρα, τμηματικα updates) δεν θα μπορουν καν να εγκατασταθουν/αναβαθμιστουν, αν απαιτουν πραγματα που δεν εχουν εγκατασταθει (π.χ. πιο νεο πυρηνα, η, το wayland). οποτε το συστημα θα παει αχρηστο
ονομαζομαι DarkGoth, και ειμαι «καλα»( ; )... το OsArena με θεραπευσε... (goth=!ok {equals} EMO)...  Emo
  Απάντηση
#47
Τι να σου πω; Έχω δει περιπτώσεις για γέλια όπου το dist-upgrade ζητάει να απεγκαταστήσει το apt (ωραία φάση θα είναι) ή που το apt σκαλώνει αλλά το aptitude κάνει σωστά τη δουλειά. Υπάρχει το
Κώδικας:
aptitude why όνομα πακέτου
(και why-not) που υποτίθεται σου εξηγεί γιατί μπαίνει/βγαίνει ένα πακέτο. Δες μήπως βγάλεις άκρη έτσι. Δεν έχει λογική η απεγκατάσταση του xorg. Ακόμα κι αν ήταν default ο Wayland (που δεν είναι), πάλι τον χρειάζεται για το XWayland.

Ρώτα στο forum του Debian. Εγώ θα έβριζα κιόλας, γιατί είναι αστεία πράγματα αυτά, εσύ όμως είσαι καλό παιδάκι και θα μιλήσεις ευγενικά.
Το άπλυτο κορμί το πλένεις. Καθαρίζει. Η βρόμικη ψυχή πώς πλένεται;
  Απάντηση
#48
@Soulrain Fails

Αν αναφέρεσαι στο ΜΑΤΕ, πράγματι, φτύσαμε αίμα να δούμε λειτουργική gtk3 έκδοση. Αλλά μιλάμε πάντα για 2 με 3 μήνες υπόθεση. Τόση είναι περίπου η καθυστέρηση για να ενημερωθεί η sid (unstable) έκδοση. Εννοείται ότι η testing και πολύ περισσότερο η stable θα καθυστερήσουν περισσότερο.
Κι επειδή παρακολουθούσα το MATE σε διαφορετικές διανομές (π.χ. manjaro), δεν ήταν και πολύ ταχύτερες ούτε λιγότερο ασταθείς οι ενημερώσεις τους.
Παλιότερα πράγματι υπήρχε μεγάλη καθυστέρηση. Π.χ. το KDE του Mepis είχε καθυστερήσει χρόνο να ενημερωθεί. Πλέον έχει βελτιωθεί σημαντικά και σ'αυτό τον τομέα το debian.
Το wayland gnome είναι επόμενο να καθυστερεί εφόσον είμαι σε stable (που θεωρητικά το υποστηρίζει). Στην testing και sid πιστεύω ότι θα τρέχει κανονικά. Αλλωστε έχει πολύ δρόμο ακόμα για να γίνει χρηστική η wayland, πόσο μάλλον να προσαρμοστούν σ'αυτή τα διάφορα DE.
Ανάλογα προβλήματα υπήρχαν και με τον Χ. Ο κώδικας γράφτηκε στα μέσα των 80's, στα τέλη ο Χ11. Παρόλα αυτά, μέχρι και το '98, το να σηκώσεις X server σε linux ήταν σοβαρό επίτευγμα, κάποιοι άνοιγαν jack daniels όταν το κατάφερναν :)

Το σημαντικότερο πρόβλημα στο debian δεν είναι το πότε γίνονται οι ενημερώσεις, αλλά το πως γίνονται. Το deb είναι αρκετά παρωχημένο και θα πρέπει να βρεθεί κάτι καλύτερο ή να αναβαθμιστεί ριζικά για να ακολουθήσει την εξέλιξη. Κι αυτό δεν είναι κάτι που αφορά μόνο στο debian αλλά και στο "δημοφιλέστερο" παράγωγό του.
СМЕРТЬ НАСИПЬИКАМ ТРУДЯШИХСЯ
  Απάντηση
#49
Περισσότερο είχα στο μυαλό μου το πρώην KDE/νυν Plasma, γιατί με αυτό έχω περισσότερη εμπειρία. Χαρακτηριστικό παράδειγμα, το KDE είχε ένα συστατικό για το indexing που λεγόταν nepomuk. Στο Plasma άλλαξε εντελώς και λέγεται baloo. Επειδή το Debian αδυνατεί να ακολουθήσει τις εξελίξεις, για πολύ μεγάλο διάστημα κατά τη μετάβαση εγκαθιστούσε ταυτόχρονα και τα δύο συστατικά, ενώ όλες οι άλλες διανομές έπαψαν το παλιότερο. Το γνωρίζω από πρώτο χέρι γιατί δοκιμάζω διανομές για να βλέπω πού βρίσκονται. Αυτό είχε σαν αποτέλεσμα να τρακάρουν και να δημιουργείται πρόβλημα. Το ίδιο συμβαίνει και με libraries και άλλα συστατικά. Επίσης, το Jessie είναι πλέον «oldstable» αλλά υποστηρίζεται μέχρι του χρόνου και μετά θα επεκταθεί άλλα δύο χρόνια. Το Jessie όμως έχει τις εκδόσεις 4.14.xx και 4.11.xx του παλιού KDE, για τις οποίες η upstream υποστήριξη έχει πάψει οριστικά, που σημαίνει ότι το βάρος πέφτει στους (σίγουρα ελάχιστους) developers της διανομής που έχουν εξειδίκευση στο συγκεκριμένο DE. Εσύ ας πούμε δεν το χρησιμοποιείς και δε σε απασχολεί. Αν ήθελα να το χρησιμοποιήσω εγώ όμως, θα ήταν τρομακτική αυτή η κατάσταση.

Φτάνοντας στο σήμερα, το Plasma και όλα τα συστατικά του (frameworks, applications κλπ) έχουν καινούργιες εκδόσεις κάθε μήνα. Το Debian δεν τις προλαβαίνει και (καλώς) έχει μείνει στην 5.8 που είναι LTS. Παρόλο όμως που οι developers του Plasma κάνουν ό,τι μπορούν, έχουν τονίσει ότι κάποια bugfixes απλά δε γίνεται να περάσουν στην LTS έκδοση, γιατί επί παραδείγματι χρειάζεται η 5.9 έκδοση του Qt αλλά η LTS βασίζεται στην 5.7. Συν το ότι έτσι κι αλλιώς το Debian δεν έχει την 5.9. Γι' αυτό και, τουλάχιστον στην παρούσα φάση, καμία deb-based διανομή δε συνιστάται για καλή εμπειρία στο Plasma.

Αντίστοιχο παράδειγμα βλέπεις και με το systemd. Έχει γίνει μεν μετάβαση αλλά δεν είναι ολοκληρωμένη (δεν ξέρω σίγουρα για τη Stretch) και συνυπάρχουν τα δύο συστήματα.

Εκτός αυτού όμως, το ίδιο το Debian αναφέρει στο documentation του ότι υπάρχουν κάποιες περιπτώσεις (ασφαλείας ή μη) όπου δε μπορεί να παρέχει κάλυψη, ακριβώς γιατί δεν προλαβαίνουν λόγω διαδικασίας ανάπτυξης. Το λένε ξεκάθαρα. Έχω αναφέρει σε άλλο θέμα μια πολύ γνωστή περίπτωση όπου οι upstream developers ενός συστατικού εγκαλούν κατ' επανάληψη το Debian (και όχι μόνο) και επισημαίνουν ότι το συγκεκριμένο συστατικό σε αυτή τη διανομή έχει τρύπες. Για εμένα αυτό δείχνει κακή πολιτική ανάπτυξης, η οποία δυστυχώς δε γίνεται να διορθωθεί με το υπάρχον μοντέλο.

Υ.Γ. Μια άλλη χαρακτηριστική περίπτωση εγγενούς αδυναμίας, που δεν τη βλέπεις τόσο σε Debian όσο σε παράγωγες διανομές αλλά την έχουν κληρονομήσει από την παρωχημένη βάση, είναι η εξής: εγκαθιστά κάποιος μια εφαρμογή και του λείπει η έκδοση 1.3.2 της τάδε βιβλιοθήκης, γιατί η διανομή έχει την 1.2.5. Η συνηθέστερη «λύση» που προτείνεται είναι να γίνει symlink το libτάδε-1.3.2.so στο libτάδε-1.2.5.so. Αυτό είναι και λάθος και επικίνδυνο, αλλά ο χρήστης βλέπει ότι η εφαρμογή «δουλεύει» και δεν ασχολείται. Μέχρι που έρχεται η στιγμή που διαλύει το σύστημα γιατί έχει κάνει μπάχαλο τα sonames.
Το άπλυτο κορμί το πλένεις. Καθαρίζει. Η βρόμικη ψυχή πώς πλένεται;
  Απάντηση
#50
Ναι, δε χρησιμοποιώ plasma και δε με έχει απασχολήσει η ανάπτυξή του. Ο κανόνας είναι να χρησιμοποιείς την έκδοση των αποθετηρίων της διανομής σου. Αν τον τηρείς ελάχιστα πράγματα μπορούν να σου αποσταθεροποιήσουν το σύστημα κι αυτά θα είναι κάτι που λύνεται με 2-3 εντολές (συνηθέστερα προβλήματα με δικαιώματα ή τεράστια αρχεία logging λόγω λανθασμένου χειρισμού).

Οι αλχημείες συνηθίζονται είναι η αλήθεια. Πέρα από τα syminks* συνηθίζεται και η προσθήκη αποθετηρίων της testing ή sid και εγκατάσταση εφαρμογών-εξαρτήσεων που δεν υποστηρίζονται από την έκδοση της διανομής σου. Είναι μια αμαρτία που την κάνω συχνά-πυκνά, αλλά πάντοτε σε δοκιμαστικό σύστημα. Τα καραγκιοζιλίκια είναι αναμενόμενα αλλά είναι εφικτή και η επαναφορά του συστήματος για τους πιο έμπειρους χρήστες.
Νομίζω πως η ανάπτυξη των appimages θα βοηθήσει πολύ στην εγκατάσταση εφαρμογών χωρίς κινδύνους.

Φυσικά δε μπορείς να εγκαταστήσεις plasma από appimage και καταλαβαίνω ότι στην περίπτωση αυτή το σύστημα του debian είναι πρόβλημα.

* Δοκιμάζοντας το MATE σε manjaro είχα καταφέρει να το τρέξω με κάποια ανάλογη αλχημεία (με ψευδή symlinks), την οποία βρήκα σε forum υποστήριξης του manjaro ή του arch. Δεν το κράτησα αρκετά για να διαπιστώσω τις επιπτώσεις, αλλά αυτό που θέλω να πω είναι ότι ανάλογες αλχημείες κάνουν όλοι, όχι μόνο οι χρήστες debian και παράγωγων.
СМЕРТЬ НАСИПЬИКАМ ТРУДЯШИХСЯ
  Απάντηση


Πάμε στο Forum:


Πλάσματα σουλατσάρουν στο νήμα: 1 Επισκέπτης(ες)