La version 7.0 de la distribution GNU/Linux Debian est sortie aujourd'hui. Elle a pour nom de code : Wheezy (le manchot en caoutchouc avec un nœud papillon rouge dans Toy Story 2).
Debian est l'une des distributions GNU/Linux les plus anciennes encore actives. Elle se veut adaptée au plus grand nombre et se nomme elle-même « le système d'exploitation universel ». Elle est aussi réputée pour sa stabilité, notamment car elle n'est pas publiée à une date fixe, mais quand elle est prête.
Elle propose aussi un nombre très important de paquets (plus de 48 000 paquets binaires dans Wheezy). Ainsi, cette distribution peut être utilisée dans de nombreux domaines d'application (bureautique, multimédia, sciences, serveur, développement, etc). Enfin, plus de 120 distributions sont (ou ont été) issues de Debian. La plus célèbre étant Ubuntu, laquelle se synchronise toujours sur Debian pour ses nouvelles versions.
Merci à Sylvestre Ledru, Symoon, antistress, jerome_misc, andrianarivony, Nÿco et jiehong pour leur contribution.
Sommaire
Développement de la version
Le développement de cette version aura duré plus de deux ans.
Le graphique représente le nombre de bugs critiques découverts au fil des années :
- en bleu : pour la version stable ;
- en vert : pour la version de test ;
- en rouge : pour toutes versions de Debian (stable, testing et unstable).
Cycle de vie de Debian/Wheezy
- septembre 2010 : le nom de code de la version est annoncé : cela sera Wheezy ;
- février 2011 : la version précédente, Squeeze, est sortie. Le développement de Wheezy est officiellement démarré ;
- fin janvier 2012 : le noyau Linux 3.2 est intégré à Wheezy. Ce noyau est choisi car il a un support à long-terme ;
- mai 2012 : sortie de l'installer alpha 1 ;
- fin Juin 2012 : les paquets sont maintenant gelés : il n'y a plus que des corrections de bugs ;
- août 2012 : sortie de l'installeur beta 1 ;
- septembre 2012 : sortie de l'installeur beta 2 ;
- octobre 2012 : sortie de l'installeur beta 3 ;
- fin novembre 2012 : sortie de l'installeur beta 4 ;
- mi février 2013 : sortie de l'installeur rc1 ;
- mi mars 2013 : ajout des dépôts de rétroportages (ou plus connu sous le nom de backports) pour pouvoir mixer stabilité et nouveaux logiciels ;
- mi avril 2013 : la sortie de la version finale est prévue pour le premier weekend de mai ;
- fin avril 2013 : sortie de l'installeur rc2.
Mises à jour des principaux logiciels
- Linux 3.2 (sortie en janvier 2012) ;
- La bibliothèque C (glibc 2.13).
Serveur
- OpenSSH 6.0p1 ;
- Apache 2.2.22 ;
- lighttpd 1.4.31 ;
- nginx 1.2.1 ;
- DNS Bind 9.8.1 ;
- MTA 0.68.2 ;
- Exim 4.80 ;
- Postfix 2.9.3 ;
- MySQL 5.5.24 ;
- PostgreSQL 9.1.4 ;
- sqlite 3.7.13.
Bureau
- X.Org 7.7 (sortie juin 2012) ;
- GNOME 3.4 (sortie fin mars 2012) ;
- KDE SC 4.8 mais avec Kmail 1 (sortie fin janvier 2012) ;
- Xfce 4.8 (sortie janvier 2011) ;
- Iceweasel et Icedove 10 ESR (sortie en février 2012) ;
- Gimp 2.8 (sortie mai 2012) ;
- LibreOffice 3.5.4 (sortie en février 2012 qui remplace OpenOffice.Org).
On peut remarquer deux petits couacs et apporter une précision. Deux couacs : la non-intégration de Kmail 2 et surtout de Xfce 4.10 qui est pourtant sorti en avril 2012, donc avant le gel des paquets. Pour Xfce, la principale raison évoquée est que la mise à jour de 4.6 (version de Debian 6) vers 4.10 n'est pas prise en charge. Quant à Kmail 2, s'il n'a pas été retenu c'est qu'il a fallu choisir entre une version 1.13.7 stable et bien testée, et une version 2 encore toute fraîche et ne disposant d'aucun outil fiable de migration au moment du gel. Les empaqueteurs ont cependant promis qu'une version récente serait fournie via les backports. Une précision : GNOME Disk Utility, alias Palimpsest, est présent en version 3.0 seulement : les versions suivantes reposent sur udisks2 au lieu de udisks et il a été décidé de conserver udisks qui est plus éprouvé et qui est également utilisé par KDE.
Développement
- Python 2.7.3 et 3.2 ;
- Ruby 1.9 (mais Ruby 1.8 encore disponible jusqu'à la prochaine version) ;
- PHP 5.4.4 ;
- GCC 4.7.2.
Les nouveautés
Deux nouvelles architectures
Pour la version précédente, Debian ne prenait pas en charge d'architectures supplémentaires. Mais la fondation avait tout de même créé la surprise en portant Debian avec un noyau FreeBSD. Cette fois-ci, deux nouvelles architectures sont maintenant de la partie :
- s390x : ordinateurs centraux IBM System z qui remplace s390 ;
- armhf : alternative à armel pour les machines ARMv7 avec unité de calcul flottant.
Voici la liste des architectures officiellement prises en charge par Debian Wheezy :
- PC 32 bits (« i386 ») ;
- PC 64 bits (« amd64 ») ;
- SPARC (« sparc ») ;
- PowerPC (« powerpc ») ;
- MIPS (« mips » (gros-boutiste — big endian en anglais) et « mipsel » (petit-boutiste — little endian en anglais)) ;
- Intel Itanium (« ia64 ») ;
- S/390 (« s390 ») ;
- System z (« s390x ») ;
- ARMv7 (ARM avec unité de calcul flottant, « armhf ») ;
- ARM EABI (« armel »).
À noter qu'un travail sur une architecture d'avant-garde est en cours en collaboration avec Ubuntu. ARMv8 64 bits est une architecture qui n'existe pas matériellement. Il existe cependant un « simulateur » disponible. Passer de 32 bits à 64 bits permettra d'améliorer principalement les performances des serveurs ARM. Voir aussi la dépêche sur le noyau 3.7.
Multiarchitecture
Une des nouveautés est la gestion de la multiarchitecture : installer sur une même machine des paquets venant d'architectures différentes. Le plus courant est évidemment le mélange entre une architecture AMD64 et i386. Mais cela n'est pas limité à ce dernier mélange. Cela peut être utile pour effectuer de la compilation croisée.
Avant, dans le cas d'architecture intel, pour installer des bibliothèques 32 bits sous Debian 64 bits, il fallait installer des metapaquets de bibliothèques 32 bits : ia32-libs et ia32-libs-gtk en général. Puis installer le logiciel (souvent privateur) en 32 bits.
Maintenant, il faut configurer les architectures à ajouter :
- Pour dpkg :
dpkg --add-architecture <arch>
- Et on installe le paquet de l'architecture notre choix :
apt-get install package:<arch>
- exemple :
# dpkg --add-architecture i386
# apt-get update
# apt-get install links:i386
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
gcc-4.7-base:i386 libbz2-1.0:i386 libc6:i386 libc6-i686:i386 libgcc1:i386 libgpm2:i386 liblzma5:i386
libssl1.0.0:i386 zlib1g:i386
Paquets suggérés :
glibc-doc:i386 locales:i386 gpm:i386
Les NOUVEAUX paquets suivants seront installés :
gcc-4.7-base:i386 libbz2-1.0:i386 libc6:i386 libc6-i686:i386 libgcc1:i386 libgpm2:i386 liblzma5:i386
libssl1.0.0:i386 links:i386 zlib1g:i386
0 mis à jour, 10 nouvellement installés, 0 à enlever et 63 non mis à jour.
Il est nécessaire de prendre 9 301 ko dans les archives.
Après cette opération, 20,9 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?n
# dpkg --remove-architecture i386
# apt-get update
# apt-get install links:i386
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet links
- Vous trouverez plus de renseignements par ici.
Système d'installation
Le système d'installation a été décrit dans une précédente dépêche.
En voici un résumé :
- Prise en charge de l'installation UEFI sur 64 bits ;
- Prise en charge du WPA ;
- Prise en charge de logiciels de synthèse vocale.
Système de fichiers temporaire
Un système de fichiers temporaire est un système de fichiers utilisant la mémoire vive, mémoire plus rapide que le disque dur mais volatile. Pour améliorer les performances de l'ordinateur, il est donc judicieux de mettre des fichiers qui sont utiles temporairement dans la mémoire vive.
/var/lock et /var/run sont maintenant montés dans un système de fichiers temporaire par défaut (alias temporary file system, ou tmpfs ; voir la spécification RunDirectory). Ces répertoires ont par ailleurs été centralisés dans le répertoire /run (configuration dans le fichier /etc/default/tmpfs) :
$ mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=612344k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=2480920k)
- /run : répertoire où est stocké tous les fichiers (généralement .pid) de chaque processus contenant le numéro du processus (pid) ;
- /run/lock : répertoire où sont stocké les fichiers de verrous (NdM: remplacement par un lien archive.org) ;
- /run/shm (SHared Memory) : répertoire où sont stockés les fichiers partagés entre processus.
Par soucis de compatibilité, des liens symboliques ont été créés :
$ ls -l /var/lock /dev/shm /var/run
lrwxrwxrwx 1 root root 8 mars 21 14:42 /dev/shm -> /run/shm
lrwxrwxrwx 1 root root 9 janv. 11 11:07 /var/lock -> /run/lock
lrwxrwxrwx 1 root root 4 janv. 11 11:07 /var/run -> /run
En bref
- Le système de fichier Ext4 est installé par défaut (à la place d'Ext3) ;
- Installation possible de systemd ;
- Installation possible d'un noyau temps réel (utile pour la MAO et les systèmes embarqués) ;
- ffmpeg remplacé par le fork libav qui a un mode de développement plus conservateur, plus proche de la philosophie de Debian ;
- suppression de bibliothèques comme Qt3 qui n'est plus du tout maintenue par Trolltech/Digia depuis au moins 3 ans ;
- Sur de nombreux paquets, des options de compilation orientées sécurité ont été activées. Elles visent à déléguer au compilateur la suppression automatique d'un certain nombre de failles courantes (stack protector, fortify sources, etc.) ;
- Travail sur le fait d'avoir Debian agnostique du compilateur. Debian pourra à l'avenir être compilable aussi bien avec GCC qu'avec LLVM/Clang (Voir aussi ici ou là).
Le thème graphique Joy a été choisi à l'issue d'un concours, et remplace le thème SpaceFun de Squeeze.
Debian 8.0
Le nom de code de Debian 8.0 a déjà été dévoilé fin juillet : ce sera Jessie. Elle sortira très probablement dans deux ans, c'est-à-dire au premier ou au deuxième trimestre 2015. Il peut être intéressant de regarder ce qu'il se passe au niveau du Google Summer Of Code 2012 et 2013 pour voir les prochaines tendances.
- Aura-t-on un autre système de démarrage qu'init ?
- Aura-t-on un autre système d'affichage qu'X.Org ?
- Aura-t-on des paquets construits avec autre chose que GCC ?
Vous le saurez dans le prochain épisode.
Aller plus loin
- Documentation des nouveautés (1060 clics)
- Notes de publication (253 clics)
- Wiki des nouveautés (181 clics)
- La dépêche de la version précédente (74 clics)
- Site officiel (627 clics)
# Debian 8
Posté par siegfried . Évalué à 0.
Une question concernant Debian 8, maintenant en testing.
Les utilisateurs qui étaient en unstable, peuvent-ils passer en testing ces jours sans dommages?
[^] # Re: Debian 8
Posté par SLMitch . Évalué à 0.
Tous les paquets de unstable sont destiné a passer en testing après quelques jours.
Vu que le testing était là pour devenir Wheezy, unstable était lui aussi similaire à testing.
Donc aujourd'hui, on doit avoir stable=testing=unstable (ou du moins au moment exact de la sortie de wheezy).
A partir de maintenant, unstable est débloqué, et va re-allimenter testing.
Tu peux donc passer de ton ancien unstable au testing sans soucis a ce niveau la, c'est même plutôt le unstable de la semaine qui vient qui va fortement bouger.
[^] # Re: Debian 8
Posté par Guinns . Évalué à 6.
L'un de nous deux doit se tromper …
Pour moi : en ce moment : stable = testing != unstable
Seuls les paquets unstable corrigeant des failles critiques de testing étaient déversés dans testing pour préparer stable.
Très bientôt, testing va lâcher stable et va rattraper unstable : stable != testing = unstable
C'est une des étapes de testing ou il faut marcher sur des oeufs lors des upgrades.
Mon conseil : y aller paquet par paquet plutôt qu'un d'un coup sec
[^] # Re: Debian 8
Posté par Guinns . Évalué à 1.
Voir ici :
http://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-testing
[^] # Re: Debian 8
Posté par kursus_hc . Évalué à 1.
Je confirme, unstable recoit des dizaines de nouveaux paquets tous les jours en ce moment. Et d'expérience (je ne suis pas expert) je déconseille testing quelle que soit la période, tandis que sid ne m'a jamais claquée dans les mains (à part X). Récemment sur sid libc6 est passée de 2.13 à 2.17 sans aucun soucis, ça veut dire quelque chose ;)
[^] # Re: Debian 8
Posté par camalot . Évalué à 1.
J'ai la même question : pour ceux en testing jusqu'à maintenant (wheezy) voulant rester en testing ?
Il suffit de remplacer les "wheezy" par "jessie" dans les sources.list ?
[^] # Re: Debian 8
Posté par claudex . Évalué à 6.
Oui.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian 8
Posté par Guinns . Évalué à 9. Dernière modification le 05 mai 2013 à 11:04.
Ou alors, si tu veux définitivement rester en testing, tu mets "testing" :)
[^] # Re: Debian 8
Posté par Loïc Blot (site web personnel) . Évalué à -10.
Unstable reste toujours unstable, la branche SID prend les paquets de experimental avec une période de rétention longue, et, si aucun bug majeur cela descend dans testing après quelques semaines.
Veepee & UNIX-Experience
[^] # Re: Debian 8
Posté par Adrien . Évalué à 10.
N'importe quoi, rétablissons vite quelques vérités :
– experimental est un dépot un peu à part, souvent pour des trucs qui ne peuvent pas trop aller dans unstable (sid) : ça casse tout, gros bugs pas encore corrigé, etc. Typiquement Qt5 va faire un bon tour dans expérimental avant d'arriver dans sid à mon avis.
– unstable (sid) est l'entrée normale des paquets dans Debian. Parfois ça peut être un peu rock'n roll : c'est là qu'est testé les mises à jour foireuses et autre joyeuseté.
– testing (jessie maintenant) est alimenté automatiquement depuis sid. Si le paquet est en bonne forme, il faut grosso modo une dizaine de jour pour passer de sid à testing. Parfois beaucoup plus, suivant les bugs bloquants ou les versions de dépendances. Là c'est plus calme, puisqu'il y a eu la maturation dans sid.
[^] # Re: Debian 8
Posté par Sylvestre Ledru (site web personnel) . Évalué à 3.
La description de Experimental est imprécise. En effet, avec le freeze, beaucoup de développeurs utilisent experimental pour uploader des nouvelles versions upstreams ou des changements importants.
Ainsi, en particulier en ce moment, les packages dans experimental sont, potentiellement, aussi fiable que dans unstable normalement.
A noter que les Debian Developers ont commencé à les uploader dans unstable cf: https://twitter.com/debianupload
[^] # Re: Debian 8
Posté par Graveen . Évalué à 6.
A la place d'utiliser les noms imagés des versions (wheezy, sid, squeeze…) tu peux utiliser les noms fonctionnels (testing, unstable, stable…)
Pour experimental, je ne sais pas s'il y a un petit nom. Sid restera toujours sid, mais pour le reste, voilà quoi.
Tu peux aussi jouer avec /etc/apt/preferences pour certains paquets que tu souhaites aller cherche dans des dépots de priorités différentes ("apt pinning").
C'est sûr que testing, unstable… font moins rếver :)
[^] # Re: Debian 8
Posté par mazarini . Évalué à 7.
Utiliser un nom comme wheezy permet de choisir le moment exact de la migration.
Que ce soit pour faire des tests avant de basculer ou simplement de choisir un moment ou l'on a le temps.
[^] # Re: Debian 8
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
rc-buggy. Mais comme Sid, ça ne change pas, et il faut noter que contrairement à unstable, testing et stable, experimental n'est pas une distribution complète, seulement un ensemble de paquets qui ont été mis là pour des raisons particulières, leur mainteneur préférant ne pas encore envoyer ces versions dans unstable.
[^] # Re: Debian 8
Posté par Xaapyks . Évalué à 3.
Tiens, question aux debianistes aguéris :
Quand on tourne en stable, et qu'une version de package nous intéresse en experimental, comment on s'y prend de façon élégante et pérenne pour l'installer ? Je parle bien sur du cas où ce package n'est pas dans les backports.
Le coup du
apt-get -t experimental install <package>fonctionne pour le moment, mais je suppose bien qu'un jour la compatibilité binaire de sid/experimental sera cassée avec stable…Donc, est-ce que c'est mort et il faut soit attendre que backports package le soft tant voulu, soit se le compiler à la main ? Ou bien apt-get est tellement supérieur à tous les package managers qu'il sait tirer les bonnes bibliothèques avec la bonne ABI quand celle de stable ne sera plus compatible ?
J'espère avoir été clair…
Je me pose cette question car j'étais jusqu'à maintenant en testing, avec quelques paquets d'experimental, et là je viens de me limiter à wheezy stable…
[^] # Re: Debian 8
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Alors, quand un paquet devient incompatible avec certaines anciennes versions de ses dépendances, le mainteneur du paquet est censé l'indiquer dans le champ Conflicts de cette nouvelle version. Donc si le paquet est bien maintenu, tu arriveras à une situation ou tu ne peux pas installer la nouvelle version.
S'il s'agit de problèmes liés à la compilation, tu peux rétro-porter une nouvelle version toi-même en la compilant, ou attendre que quelqu'un le fasse pour toi dans les backports en effet.
[^] # Re: Debian 8
Posté par Xaapyks . Évalué à 4.
En regardant de plus prêt, toutes les dépendances sont versionnées ">=x.y.z" donc OK, au moins j'ai, je pense, la garantie de tirer un binaire et toutes les libs qui vont bien avec.
Et je viens de voir : (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html)
Parfait !
[^] # Re: Debian 8
Posté par freem . Évalué à 1.
2 solutions: booster les preferences ou utiliser aptitude. Tu peux aussi mélanger les deux, comme tu préfères.
Preferences:
Il faut commencer par monter la priorité du paquet dans experimental dans /etc/apt/preferences afin que le système tente de le mettre à jour lors des maj normales.
Le souci est que les dépendances ne suivront pas, il faut donc également spécifier des priorités correctes pour celles-ci.
Aptitude:
Utiliser aptitude, et pas apt-get (je rappelle que aptitude est l'outil conseillé par debian au passage. Enfin, il me semble - je l'ai vu aussi ailleurs, mais flemme de chercher plus loin que ça - ) qui est capable d'analyser diverses solutions et de te donner le choix.
Je ne peux pas trop te conseiller plus à ce sujet, vu que j'utilise principalement aptitude en mode semi-graphique, qui me permets de régler les conflits potentiels à la main et de voir bien plus facilement quelles mises à jour viennent d'upstream ou juste d'un patch d'un mainteneur debian : en cas de maj upstream, j'aime aller voir les changelogs, alors que les logs de debian ne sont liés qu'a des choses sans intérêt pour l'utilisateur de bureau que je suis (pour un serveur, j'imagine qu'il vaut mieux lire).
[^] # Re: Debian 8
Posté par claudex . Évalué à 4.
Je ne vois rien de tel dans la documentation officielle http://www.debian.org/releases/stable/amd64/ch08s03.html.fr#idp7196496
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian 8
Posté par jihele . Évalué à 2.
Je crois que ça a été le cas (pour Wheezy, je crois) du fait de limitation d'apt-get sur la gestion des dépendances en particulier mais que ça ne l'est plus car ces limitations n'existent plus. Ce serit donc à nouveau apt-get qui serait recommandé.
J'utilise aptitude aussi et maintenant que j'ai commencé je le garde pour conserver l'état "installé automatiquement" de mes paquets, même si je change de version de distro. En tout cas tant qu'aptitude est maintenu.
C'est quand même pratique, aptitude, puisqu'à la fois rapide et puissant. Il manque quelques filtres automatiques (tri par dépôt d'origine, par exemple), mais ça reste bien.
[^] # Re: Debian 8
Posté par freem . Évalué à 3.
Même dpkg est capable de gérer l'état automatique (il m'arrive régulièrement de devoir télécharger un paquet et ses dépendances sur une machine pour les balancer sur une autre via un média par exemple, et ensuite faire un "dpkg -i *" dans le bon dossier. Et les paquets qui sont imposés par une dépendance à un autre paquet que l'on est en train d'installer sont marqués en automatique.)… pour apt-get je ne sais pas par contre, mais en tout cas je n'ai pas l'impression que mixer apt-get, dpkg et aptitude (selon mon humeur j'utilise l'un ou l'autre) affecte mon système.
Par contre, même si j'aime beaucoup aptitude (c'est celui que j'utilise majoritairement) aussi, tu as oublié quelques défauts (au mois présents en mode semi-graphique): il est lent, et il est aussi peu voire pas adapté a multi-arch (les paquets apparaissent en double: i386 et amd64… ça ne rend pas la navigation plus simple.)
Il y a dselect qui a l'air pas mal aussi, mais qui n'est pas très encouragé, surtout pour les débutants… Vu que je pense que je ne suis plus un total débutant avec les gestionnaires de paquets debian, je me dis que je pourrais tenter de jouer un peu avec… (j'ai déjà vu des gens en parler sur la ml, ça a l'air puissant)
[^] # Re: Debian 8
Posté par freem . Évalué à 1.
Précision au sujet de dpkg: il ne supprime pas les paquets qui ne sont plus nécessaires, il se contente de mettre le flag automatique tout seul dans la manip que j'ai décrite. (que ce soit clair)
[^] # Re: Debian 8
Posté par jihele . Évalué à 1.
Je n'ai jamais testé mais j'ai lu précisément le contraire ! Attention. (Ça doit pas être trop dur à tester…)
Je ne l'ai jamais trouvé lent. Jusqu'à ce que je l'utilise sur un Raspberry Pi. Sur mon PC le tri se fait rapidement et j'ai très vite la main après le lancement.
Multi-arch j'utilise pas, mais ça doit faire partie des options manquantes au même titre que le tri par dépôt. Ça devrait pas être si compliqué à rajouter.
Je comprends qu'il ne soit pas recommandé : l'approche est peut-être de préconiser Synaptic et de laisser les plus expérimentés passer à apt-get en ligne de commande, qui partage la gestion de dépendances auto de Synaptic.
Je n'utilise aptitude presque qu'en mode ncurse et je le préfère à Synaptic, justement. Et puis ça a le mérite de me faire la même interface sur le PC que sur le serveur et le Rapsberry Pi. Mais on peut pas proposer ça a un débutant si on veut le garder. Pas tout de suite.
[^] # Re: Debian 8
Posté par claudex . Évalué à 9.
Ce fut le cas du temps de Etch mais depuis, le problème est résolu.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian 8
Posté par jihele . Évalué à 1.
C'est une bonne nouvelle (enfin c'est peut-être nouveau que pour moi…). Ça veut dire qu'on peut installer une Debian avec Synaptic chez un débutant et intervenir dessus en utilisant aptitude sans mettre le bazar.
Merci pour l'info.
[^] # Re: Debian 8
Posté par freem . Évalué à 1.
J'ai toujours utilisé aptitude (le semi-graphique, j'adore, j'y peut rien…) mixé avec apt-get (parce qu'au début je suivait les conseils des forums quand j'avais un problème précis) et ma première installation (en tout cas, que j'aie réellement utilisée) de Debian était une Lenny.
Je n'ai jamais eu de soucis de ce côté là.
Je le trouve lent sur mon 1015PEM, et lors de 2 évènements (dont l'un est plus bloquant que l'autre):
Je ne comprend pas ce que tu veux dire au sujet du partage de gestion des dépendances… aptitude est, comme apt-get et synaptic, un front-end à dpkg.
Quant à synaptic… les rares fois ou j'ai voulu m'en servir, j'ai monstrueusement galéré à installer un paquet, et je n'ai même pas réussi à comprendre les implications de ce que je faisais sur mon système!
C'est marrant de constater que je n'ai eu aucune difficulté à m'approprier aptitude qui est en ncurses… bon, je pense que ça viens du fait que mes débuts dans le dev se sont faits avec QB 1.1 et turbo C, donc que j'ai toujours été habitué aux interfaces ou il n'y a pas de fioritures (et que les 1ers PC que j'aie vu utilisaient DOSSHELL avant ce bon vieux win3.1)…
Mais bon, les dev de synaptic et d'aptitude-gtk (je me demande ou en est le dev de celui-ci d'ailleurs?) ont quand même fait des interfaces assez crades pour moi.
Je ne recommanderait certainement pas ces choses à un débutant.
Je ne suis pas si sûr.
Je m'étais déjà promis d'aller voir le code source, mais je pas eu vraiment envie de fouiller très loin quand j'ai vue l'arborescence (dans src/ il y a pas mal de
bazardossiers - qt, mine, gtk, generic et cmdline - et une énorme dose de fichiers sources qui ne semblent pas très structurés. On peut aussi noter les 100 lignes d'include pour le fichier src/main.cc… Ca donne pas trop envie je trouve, même si je comprend bien qu'un tel programme soit complexe.) des fichiers.Même si je me trompe sur ma première impression de boxon, le fait est qu'il semble y avoir des implémentations pour au moins 4 interfaces différentes, dont 3 graphiques (ncurses, qt et gtk) ! Alors pour le fait que ce soit simple d'ajouter une fonctionnalité dans ces conditions, j'ai un doute.
Ca doit être assez pénible pour s'y mettre quand même. Je précise malgré tout que je n'ai jamais tenté d'approcher l'un des dev non plus, j'ai juste "jeté un oeil" comme on dit.
Pourquoi?
Parce que l'interface n'est pas jolie?
C'est tout de même moins pire que de recommander apt-get et sa ligne de commande, et sur les forum ça ne parle presque que d'apt-get…
Ne me parle pas des raccourcis clavier exotiques (le "/" pour la recherche peut sembler exotique à un nouvel utilisateur qui ne connaît que les IHM modernes, mais on s'y fait vite): les débutants n'utilisent pas les raccourcis clavier mais vont commencer par cliquer je pense.
Là encore, je peux me planter, mais il me semble que Debian n'a jamais réellement ciblé les utilisateurs débutants (l'installateur par défaut n'est par exemple pas le plus simple de la liste, qui ne pose quasiment aucune question), et si quelqu'un utilise Debian, je doute que ce soit une personne avec le niveau 0 en terme de technicité: Debian n'est pas réputée pour être simple (je parle de réputation ici, pas de faits).
[^] # Re: Debian 8
Posté par jihele . Évalué à 2.
Oui, j'ai recherché une source exacte, pas trouvé. Apparemment c'est plus vrai depuis longtemps, tant mieux.
Il me semblait que l'état "installé automatiquement" était stocké dans une base de donnée propre à aptitude, pas à dpkg. Et donc bazar si on mélange les deux.
J'ai commencé avec Ubuntu/Synaptic et je trouvais ça pas mal. Autant je suis fan d'aptitude en ncurse, autant je persiste à dire que c'est précisément le genre d'interface qui fait fuir un débutant, que ça soit l'apparence, les raccourcis, etc. Synaptic a aussi une interface de gestion des dépôts qui évite de devoir éditer sources.list à la main. Et je me vois pas proposer un linux à un débutant s'il n'y a pas un truc comme ça. Et l'applet de mise à jour automatique (update-notifier).
Je préfère moi aussi l'interface ncurse d'aptitude à une ligne de commande apt-get ou aptitude. L'avantage de la ligne de commande est qu'elle se copie facilement sur un forum.
Je sais pas, mais l'installeur par défaut me semble pas mal et permet à un débutant d'installer et d'avoir un système joli qui tourne. Sous réserve de comprendre qqchose à Gnome Shell (moi j'y comprends rien), ou a un autre bureau de son choix, il peut se débrouiller. Donc autant avoir un système complètement "accessible".
Si je dois installer un linux chez un proche, j'hésite entre stable/Xfce et testing/Xfce, selon son expertise, son besoin de bleeding-edge, et ma proximité.
[^] # Re: Debian 8
Posté par barmic . Évalué à 5.
Pour les cas simples, tu peut recompiler assez facilement :
Ça permet de résourdre les incompatibilité uniquement liés à des problèmes d'ABI.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Architecture
Posté par claudex . Évalué à 6.
Pourquoi l'architecture System Z s'appelle « s390 x » et pas « s390 z » ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Architecture
Posté par xunfr . Évalué à 4.
"x" pour kernel 64-bits de la série z: source
[^] # Re: Architecture
Posté par wilk . Évalué à 3.
A propos d'architecture est-ce possible à partir de maintenant d'upgrader d'une archi à l'autre sans refaire une installation ou c'est encore pour plus tard ? Sur une page du wiki ça n'est pas très clair…
[^] # Re: Architecture
Posté par freem . Évalué à 1.
Je pense que c'est faisable, au moins pour l'ajout d'une archi.
Pour la suppression de l'ancienne arch, je n'en mettrait pas ma main à couper: je n'ai encore jamais réussi à supprimer i386 personnellement, même avec amd64 installée (qui était d'ailleurs la principale et la première archi, l'autre n'ayant été installée que pour skype et wine, que j'avais bien entendu virés ainsi que tout paquet i386 avant de vouloir virer l'archi x86).
# Précision concernant tmpfs
Posté par xunfr . Évalué à 5.
/lib/init/rw a été supprimé de la liste des fichiers système de type tmpfs. La configuration se fait dorénavant sous /etc/default/tmpfs, avant sous /etc/default/rcS.
==> Note de version sur tmpfs (notamment pour architectures amd64 et i386)
# release vu de l'intérieur
Posté par i M@N (site web personnel) . Évalué à 5.
sur son blog le ftpmaster Joerg Jaspert raconte (anglais) http://blog.ganneff.de/blog/2013/05/wheezy-release.html
wind0w$ suxX, GNU/Linux roxX!
# Sécurité des navigateurs
Posté par trucmachin973 . Évalué à 3.
Dans les notes de version, il est indiqué que les navigateurs basés sur webkit ou khtml ne sont pas pris en charge par l'équipe de sécurité, et qu'il est recommandé d'utiliser iceweasel ou chromium ( http://www.debian.org/releases/wheezy/amd64/release-notes/ch-information.en.html#browser-security ).
Or, si on lance debscan sur sa machine on voit que iceweasel a un nombre important de problème de sécurité.
Comment ça se fait ?
[^] # Re: Sécurité des navigateurs
Posté par claudex . Évalué à 10.
Parce que justement, ils sont pris en charge par l'équipe de sécurité et que donc les problèmes sont rapportés.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Un dimanche sous le signe d'apt
Posté par Sébastien . Évalué à 4.
Merci pour cette dépêche.
Je me prépare une double ration de café :)
# Conservatisme
Posté par rpnpif . Évalué à 4.
Mouais.
D'un côté : Conservation des bogues de l'ancien ffmpeg dans libav.
De l'autre côté : Correction de certains vieux bogues dans ffmpeg originel mais, avec création de nouveaux bogues.
Conclusion : conservatisme contre nouveauté, score 1 partout !
Même problème entre le noyau de wheezy ou squeeze-backports (3.2) versus le dernier stable 3.8 (de Linus). D'un côté, plantage de certaines applications comme Libreoffice, de l'autre la console Linux ne fonctionne plus en mode KMS. Ne parlons pas des grandes lenteurs de celui de Squeeze (2.6) avec ma (vieille) carte Radeon (insupportable au quotidien).
Je ne parle que du mode bureau. En mode serveur, je n'ai pas vraiment de souci.
Pas simple tout ça.
[^] # Re: Conservatisme
Posté par patrick_g (site web personnel) . Évalué à 10.
s/3.8/3.9
Sinon pour moi la chose la plus gênante dans cette Wheezy c'est l'antique version 4.8 de Xfce. La raison invoquée est risible (l'update de 4.6 en 4.10 n'est pas supporté) puisque cela ne fait que reporter le problème. Comment feront-ils pour Jessie si l'upgrade entre 4.8 et une version plus récente n'est pas supportée ? Il y aura perpétuellement deux ou trois versions de retard ?
C'est d'autant plus grave que le passage à Gnome 3 a renforcé l'attractivité d'Xfce pour beaucoup d'utilisateurs. Leur proposer une version datant de janvier 2011 c'est quand même grave je trouve.
Mais bon je grogne, je grogne mais je n'ai pas les mains dans le cambouis comme les devs Debian alors bravo à eux pour cette release.
[^] # Re: Conservatisme
Posté par coid . Évalué à 2. Dernière modification le 05 mai 2013 à 11:20.
Toujours le même problème :
— l’OS Linux est décentralisé en multiples distributions,
— mais chaque distribution trouve bon de centraliser l’écosystème logiciel.
Logique.
Tu connais sûrement, mais peut-être pas d’autres :
https://plus.google.com/109922199462633401279/posts/HgdeFDfRzNe
Ça doit être dur de suivre tous les logiciels.
[^] # Re: Conservatisme
Posté par rakoo (site web personnel) . Évalué à -6.
Donc en fait, il est en train de dire que Archlinux est la meilleur distribution qui est parce qu'elle reste le plus près possible d'upstream, au prix parfois de la stabilité ?
[^] # Re: Conservatisme
Posté par rpnpif . Évalué à 0. Dernière modification le 05 mai 2013 à 11:31.
Ah oui, mais la dernière mise à jour, c'est bien la 3.8.11 à 2 jours près (ouf, je m'en sors bien là) ;-).
Je m'en vais, de ce pas, patcher vers le 3.9. Merci.
Alors que pour Gnome 3, ils semblent être plus coulant. Dommage.
Mais peut-être manquent-ils de ressources ?
[^] # Re: Conservatisme
Posté par ZeroHeure . Évalué à 4.
Les équipes de développeurs Debian sont indépendantes. Celle qui empaquête Xfce n'est pas celle qui s'occuppe de Gnome. Elles ont fait des choix différents.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Conservatisme
Posté par Kioob (site web personnel) . Évalué à 1.
Et accessoirement cette Wheezy sort avec Gnome 3.4, qui a plus d'un an. Ce n'est certes pas aussi ancien que les 2 ans de Xfce, mais j'aurais aimé y voir une 3.6.
alf.life
[^] # Re: Conservatisme
Posté par claudex . Évalué à 9.
Sauf que le 3.8.11, il n'est pas de Linus mais de Greg Kroah-Hartman
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Conservatisme
Posté par barmic . Évalué à 7.
Je pense que ça va dépendre de si, les développeurs d'XFCE se rendent un jour compte que leurs utilisateurs (ou leurs éventuels futurs utilisateurs s'ils concurrence Gnome) n'ont pas forcément envie de refaire leur configuration à chaque nouvelle version. Pour ça ils ont 2 solutions :
Ça ne me paraît pas déconnant comme solution.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par Adrien . Évalué à 2.
peut-être aussi que les empaqueteurs Debian pour XFCE manquent de main d'œuvre pour faire tout bien comme il faut pour chaque version qui sort ? Dans d'autres équipes (KDE) c'est comme ça que ça se passe.
[^] # Re: Conservatisme
Posté par barmic . Évalué à 2.
Tu veux dire que l'équipe d'XFCE contrairement à celle de KDE n'est pas en mesure de pallier les manques upstream ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par Adrien . Évalué à 3.
Non, c'est sans doute pareil des deux côtés. Kmail2 vient tout juste d'entrer dans experimental, on est passé de KDE 4.6 à 4.8 à 4.10.
Je suppose que côté XFCE ça doit être les mêmes problèmes, le manque de petites mains en est un.
[^] # Re: Conservatisme
Posté par moatib . Évalué à 10.
Votre commentaire est dans le faux ! Nous n'avons pas eu à « refaire notre configuration » depuis Xfce 4.6 il y a plus de quatre ans et la migration de version en version est automatiquement prise en charge par des scripts gracieusement fournis par les devs de Xfce depuis au moins Xfce 4.2 en 2005 pour faciliter la vie des utilisateurs et des mainteneurs de Xfce dans les différentes distributions GNU/Linux.
Ce sont les mainteneurs de Xfce dans Debian qui ont refusé de prendre en charge la migration de Xfce 4.6 de Squeeze vers 4.10 dans Wheezy :
http://corsac.net/?rub=blog&post=1546
[^] # Re: Conservatisme
Posté par freem . Évalué à 0.
Hum… Ce message ne fais qu'indiquer qu'il y avait des bugs critiques dans la version qui était en sid. Il n'y a aucune mention des scripts dont tu parles?
[^] # Re: Conservatisme
Posté par moatib . Évalué à -1.
Le lien de mon message précédent pointe vers le blog du mainteneur de Xfce de Debian et on voit bien que c'est lui qui ne voulait pas se prendre la tête avec la transition de Xfce 4.6 vers 4.10.
Pour ce qui est de mon allusion sur les scripts fournis par les développeurs de Xfce, tout utilisateurs de longue date curieux de l'évolution de son développement sont au courant de ce fait. Même la transition de la version 4.4 avec son ancien système de configuration (xfce4-mcs-manager) vers la version 4.6 et le nouveau système de configuration (xfconf) a été entièrement prise en charge par les scripts des devs de Xfce.
[^] # Re: Conservatisme
Posté par barmic . Évalué à 1.
Tu vois ça où ? Moi ce que je lis (mais je ne suis pas bilingue), c'est que Xfce 4.10 a pas mal de bug critique et qu'il ne se voit pas arriver à tous les corriger pour la sortie de Wheezy. Il indique tout de même qu'il est ouvert sur le sujet et que si on l'aide à corriger ces bugs, alors oui ce serait devenu possible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par xcomcmdr . Évalué à 2.
C'est pas le cas sous Archlinux, Xubuntu 12.04 + PPA Xfce 4.10, Xubuntu 12.10, et Xubuntu 13.04, Ubuntu Studio 12.04 + PPA Xfce 4.10, Ubuntu Studio 12.10, Ubuntu Studio 13.04, Zenwalk, …
Xfce 4.10 date du 29 avril 2012, il a plus d'un an.
Et pas mal de composants sont sorties en versions 4.10.1.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Conservatisme
Posté par barmic . Évalué à 2.
Donc tu lui recommande de passer à Archlinux ? La question n'est pas de la qualité de Xfce ou pas, mais de l'empaquetage. Peut être que ça vient du ou des packagers ou d'upstream, le problème c'est juste qu'il y avait trop de bug pour que le packagers se sentent de se coller à la tâche pour Wheezy (mais si quelqu'un se serait sorti les doigts, vu comme un certains nombre de commentaires ont l'air de dire que c'est simple à empaqueter), il affirme qu'il aurait tout à fait accepté de l'aide.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par xcomcmdr . Évalué à 2. Dernière modification le 10 mai 2013 à 16:39.
Non ! Pourquoi ?!
Mais QUELS bugs ?
Je n'en ai vu aucun, même à la migration entre 4.8 et 4.10, et depuis le temps pas mal ont été résolus (et ce bien avant la sortie de Wheezy)
Quant à l'empaquetage, si les mainteneurs de Xubuntu, Ubuntu Studio, Arch, Zenwalk, et d'autres l'ont fait, ça doit :
1.être pas bien difficile
2.Facile d'avoir de l'aide
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Conservatisme
Posté par barmic . Évalué à 6.
J'en sais rien faut demander au développeur dont le boulot c'est de les corriger et qui a trouvé la tâche trop ardue pour lui.
Pas suffisamment de monde ne lui a donné de coup de main en tout cas (peut être qu'à force de voir des gens pas contents il va réagir mais c'est à mon humble avis pas le plus efficace). Il a était clair sur sa position et il semble ouvert. Je vois pas ce qu'il y a à lui reprocher. Peut être qu'il est mauvais, lent ou qu'il manquait de temps, mais à ce moment là ce n'est pas avec ce genre de critiques que les choses vont s'arranger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par moatib . Évalué à 1. Dernière modification le 14 mai 2013 à 14:55.
« Due to this timing (and the fact Squeeze has 4.6 and doing a 4.6 → 4.10 upgrade needed some tuning in various packages), it was decided to not try to push 4.10 into Wheezy that late in the release cycle. »
C'est la principale raison pour laquelle Xfce 4.10 n'est pas dans Wheezy, à savoir que, pour faire la transition de Xfce 4.6 vers 4.10, quelques paquets Debian de Xfce avaient besoin de « tunning » (d'ajustements). C'est principalement par paresse du mainteneur de Xfce dans Debian que nous n'avons pas Xfce 4.10 dans Wheezy et que nous sommes pris avec la version 4.8 vielle de plus de deux ans !
Et quand Corsac (Yves-Alexis Perez, mainteneur de Xfce dans Debian) écrit ceci à propos des bogues critiques :
« So, if you want to have Xfce 4.10 in Debian sid/testing sooner, then the easiest and fastest way is to fix some release critical bugs so we can release sooner, and then start breaking sid by uploading a whole lot of new stuff there. »
Il demande aux utilisateurs de Debian/Xfce « impatients » de voir Xfce 4.10 arriver plus rapidement dans Unstable/Testing, de corriger les bogues critiques de Debian pour que Wheezy sorte plus rapidement et ainsi voir Xfce 4.10 passer de Experimental vers Unstable (et après, longtemps après, dans Testing). Il n'y a aucune mention de bogues critiques de Xfce 4.10 dans le texte de Corsac.
Vous auriez intérêt à prendre des cours d'anglais avancés…
Et dix jours après la sortie de Wheezy, à part un nouvel upload de lightdm qui n'a rien à voir avec Xfce, c'est le vide absolu dans le SVN de pkg-xfce Debian !
Je serais même presque prêt à mettre ma main au feu que Xfce 4.12 verra le jour avant même que Xfce 4.10 soit utilisable dans Debian Unstable/Testing. Dans ces conditions, on est loin, très loin, de pouvoir affirmer que les utilisateurs de Xfce dans Debian peuvent contribuer à l'amélioration et la correction de bogues des versions récentes de Xfce…
[^] # Re: Conservatisme
Posté par xcomcmdr . Évalué à -9. Dernière modification le 21 mai 2013 à 12:43.
Donc Debian introduit des bugs, CQFD.
---> []
Quant aux cours d'anglais avancées, je crois qu'un score TOEIC 935/990 et une pratique quotidienne depuis 15 ans est plus que suffisante.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Conservatisme
Posté par vv222 . Évalué à 4.
XFCE 4.10 est arrivé en Sid, et la 4.12 n'a pas encore été publiée !
De quelle main vas-tu te passer ? ;)
De tous ceux parmi vous qui critiquent le retard de XFCE dans Debian, combien ont proposé des patches aux mainteneurs pour accélérer le processus ?
Le clientélisme est généralement réservé aux gens qui payent pour un service, pas à ceux qui profitent gracieusement du travail de bénévoles…
[^] # Re: Conservatisme
Posté par Maclag . Évalué à 3.
C'est malin ça!
Comment veux-tu qu'il publie des patches à l'avenir aussi rapidement qu'il veut voir les versions avancer s'il n'a plus qu'une seule main?
Et voilà, en plus de proposer des versions obsolètes de logiciels, il dira en plus que Debian lui a coûté sa main!
[^] # Re: Conservatisme
Posté par symoon . Évalué à 8.
Quel scandale ces développeurs bénévoles qui n'ont des fois pas le temps disponible pour répondre à toutes les exigences des utilisateurs jamais là pour contribuer, mais toujours là pour raler sur LinuxFR !!
[^] # Re: Conservatisme
Posté par freem . Évalué à 3.
C'est normal que Debian sois restée en 3.2, puisque c'était la version stable au moment du gel. Malgré ça, les problèmes de sécurité sont encore fixés, ce ne sont que les versions qui apportent des nouvelles fonctionnalités qui sont gelées, même si, oui, les nouvelles fonctionnalités incluent des pilotes.
Sinon, t'as les backports aussi, si tu veux un kernel moins vieux avec Debian stable.
Oui et non…
J'ai déjà fait des mises à jour de XFCE4, et je me suis retrouvé avec un truc réinitialisé aux valeurs par défaut. Pas terrible, et pourtant c'était une MaJ de la 4.8 à la 4.10 (de testing à sid… ou était-ce vers experimental?). Ca, ça pourrait peut-être encore passer, mais ce document semble indiquer que c'est encore pire.
Ce qui m'intrigue, c'est surtout comment il se fait qu'une MaJ entre 2 versions mineures (en admettant que le semantic versionning soit utilisé) ne soit pas capable de migrer sans problème, même si une version à été sautée entre deux?
Debian ne veux pas que les mises à jour cassent le système, et c'est tout à fait compréhensible.
Si je ne m'abuse, ces utilisateurs n'étaient pas utilisateurs de Debian stable, sinon ils seraient restés à Gnome 2 et n'auraient jamais testé gnome 3.
Donc, je me permets d'en déduire que les debianneux qui sont passés à XFCE à cause de gnome 3 sauront comment faire pour passer à XFCE4.10.
Pour les gens qui arrivent sur Debian, il est quand même de notoriété commune que la stable soit dotée de logiciels vieillissants, et personnellement je ne conseillerai pas l'usage de Debian stable pour un usage de bureau. Testing est bien plus intéressante dans ce cas: logiciels moins vieux, surtout pour les navigateurs (plutôt utile en ce moment) et bonne stabilité: de mémoire, Ubuntu se base sur Debian unstable, c'est dire.
Oui, car la philosophie de Debian est d'éviter de casser quand on mets à jour. Ceux a qui cette philosophie ne plaît pas, n'utilisent pas Debian, ou alors pas en stable. Il y a largement assez de distributions pour que des utilisateurs qui veulent absolument la dernière version d'un logiciel puissent trouver ce qu'ils veulent.
[^] # Re: Conservatisme
Posté par xcomcmdr . Évalué à 3.
Sous Archlinux ou Xubuntu, je suis passé de Xfce 4.8 à Xfce 4.10 sans rien perdre.
Le seul truc que j'ai eu à faire dans les deux cas, était de mettre un séparateur en mode étendu après la liste des fenêtres dans le tableau de bord (dans Xfce 4.10, la liste des fenêtres n'étend plus le tableau de bord).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Conservatisme
Posté par Raphael R . Évalué à 2.
Je ne peux que plussoyer ceci, le passage de la 4.8.6-1 à 4.10.0-1 sur ma Arch en Testing n'a pas posé de problème mis à part ce drôle de séparateur. Alors du coup, j'ai du mal a comprendre comment cela se fait que la Debian il y ait eu perte de profil.
[^] # Re: Conservatisme
Posté par fmaz fmaz . Évalué à 1.
En même temps, si c'était un bug qui arrivait systématiquement, on peut quand même imaginer qu'il aurait été corrigé.
Donc le fait que sur deux exemples, la migration se soit bien passé n'est pas forcément une preuve du fait qu'il n'y a pas de problème.
[^] # Re: Conservatisme
Posté par xcomcmdr . Évalué à 1.
Sur Xubuntu, énormément de gens ont installé le PPA de Xfce 4.10 sans aucun problème.
Il n'y a pas beaucoup de changements entre la 4.8 et la 4.10, de toutes façons (je n'ai pas dit que ces changements étaient sans intérêt).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Conservatisme
Posté par xcomcmdr . Évalué à 7. Dernière modification le 05 mai 2013 à 12:02.
Euh, juste non.
C'est ffmpeg le plus conservateur :
- garde le vieux code des vieux codecs
- compatibilité avec les arguments en ligne de commandes de libav
Là où libav vire le code non-maintenu, essaie de se faire passer pour le projet upstream/officiel (NON ffmpeg n'est pas abandonné !), et multiplie les bugs et les incompatibilités avec les "anciens" arguments en ligne de commande de ffmpeg.
Source
Pour ma part, je préfère ffmpeg, et pas libav qui se fait passer pour le paquet ffmpeg (comme c'est le cas sous Debian/Ubuntu, merci aux mainteneurs)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Conservatisme
Posté par patrick_g (site web personnel) . Évalué à 7. Dernière modification le 05 mai 2013 à 12:11.
Il y a certainement des torts des deux côtés qui ont conduit à ce fork.
Pour rétablir la balance par rapport à ton post il faut lire la partie "History" de http://libav.org/about.html
A titre perso je fais confiance aux devs de Debian pour leur choix. C'est un peu comme le passage sur la EGLIBC qui avait été décidé pour éviter d'avoir à subir Ulrich. Quand le leader d'un projet est une foutue tête de lard il n'est pas étonnant que les utilisateurs fuient.
[^] # Re: Conservatisme
Posté par Misc (site web personnel) . Évalué à 2.
s/utilisateurs/empaqueteurs/
la plupart des utilisateurs savent à peine que la glibc existe.
( et puis, en matière de tête de lard, y a linus, y a theo de raadt, mais bon, pour eux, c'est normal d'être colérique alors on accepte )
[^] # Re: Conservatisme
Posté par claudex . Évalué à 9.
Linus est peut-être colérique mais au final, il accepte pas mal de chose (cf. les différents système de sécurité qui existent).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Conservatisme
Posté par barmic . Évalué à 7.
On parle d'utilisateurs au sens utilisateur de la bibliothèque par exemple et pas nécessairement utilisateurs finaux.
C'est une question de leadership, s'il n'y a pas d'alternative ou que personne n'imagine te remettre en cause alors tu peut te permettre des dérapages et autre sans perdre tout d'un coup. Pour Linus personne n'imagine sereinement reprendre ce qu'il fait, il est le seul légitime actuel. Pour Theo De Raadt ça lui a déjà posé problème avant qu'il ne lance OpenBSD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par Misc (site web personnel) . Évalué à 5.
En même temps, le noyau est un logiciel les plus forkés. Toute les distros ont des patches qui changent le comportement, certaines dépendent même de module qui n'ont pas été admis upstream ( genre les livecds ), d'autres font leur beurre sur ça ( genre openvz ), voir rajoute des API qui font des noyaux impacompatible ( khof android khof )
Je vais pas défendre Ulrich Drepper car je pense qu'il avait un comportement de merde, mais on a évité le même genre de souci sur la glibc en partie grâce à lui.
[^] # Re: Conservatisme
Posté par barmic . Évalué à 5.
Toutes ces pratiques diminuent fortement avec le temps. Les distributions ajoutent peut être des patches, mais elles n'en sont plus dépendantes (Debian par exemple), openvz semble déprécié et intégré par petits bout au noyau (j'avais lu que c'était aussi un objectif d'un GSoC de l'an dernier ou l'année d'avant pour GRSecurity) et Google reverse au fur et à mesure ses développements à vanilla (il y avait l'ojectif de lancer android avec vanilla à partir d'une date ou d'une version donnée je crois).
Je ne dis pas que ça n'existe plus, je dis que c'est de moins en moins le cas. Suivre le développement du noyau depuis l’extérieur c'est très chère (GRSecurity ne supporte que certaines versions du noyau par exemple). Il reste des parties « simples » qui peuvent être maintenu depuis l'exterieur car l'interfaçage avec le reste du noyau est clair (par exemple les systèmes de fichiers comme zfs ou unionfs 2).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Conservatisme
Posté par Antoine . Évalué à 2.
En quoi est-ce que ça remet en cause la façon dont Torvalds gère le projet ? Les distros patchent n'importe quel logiciel important et ne prennent parfois même pas la peine de communiquer avec le projet d'origine.
La surface de contact de la glibc avec les contigences externes est tout de même beaucoup plus réduite. La glibc implémente principalement les API C et POSIX, il n'y a rien de terriblement sujet à divergence là-dedans (vu que c'est normalisé), et donc peu de raisons de forker.
[^] # Vous n'aimez pas android ?
Posté par kadalka . Évalué à -10.
Merci de ne pas être grossier.
Ce n'est pas votre genre j'espère…
Vous n'aimez pas android ? Problème c'est ce que tout le monde veut, enfin presque.
Vous nous conseillerez quoi à la place.
Rassurez moi: pas iOS hein ?
[^] # Re: Conservatisme
Posté par ZeroHeure . Évalué à 1. Dernière modification le 05 mai 2013 à 12:12.
Mouais, c'est un peu simpliste. Reinhard Tartler l'a très bien expliqué dans l'email référencé dans la dépêche: why libva over ffmpeg. Pour le citer: "there is a lot of confusion going on here". En fait depuis le fork, libav a bien changé, et "Libav is much more a continuation from what FFmpeg used to be".
Concernant les nouveautés, "all new important features are developed in Libav trunk properly first".
Enfin, les patchs de sécurité ne sont pas décris dans FFmpeg.
FFmpeg est toujours disponible via les paquets de Christian Marillat, mais il cause des bogues subtils avec les applications qui sont compilées avec libav.
Bref, le choix a été comme d'habitude pragmatique.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Conservatisme
Posté par vpinon . Évalué à 5.
On en a déjà discuté lors de la sortie de ffmpeg 1.0. Je continue de penser que le fork libav a pu être nécessaire à un moment pour faire bouger les lignes, mais que la déclaration "ffmpeg obsolète" est limite malhonnête.
Je trouve le mainteneur debian partisan (les 2 camps se sont fait des coups bas, et il fait partie d'un des bords).
J'aimerais que l'équipe donne accès aux 2 paquets, l'un excluant l'autre en cas de recouvrement (c'est du boulot, et je n'ai pas investit le temps pour apprendre à contribuer à debian).
Moi je constate juste que MLT/Kdenlive marche mieux quand je compile depuis les sources avec ffmpeg plutôt que quand j'utilise le paquet basé sur libav. Je n'ai pas cherché d'où ça vient mais c'est juste un constat que mon audio ne se décale pas, mes profils d'encodage gardent des paramètres qui marchent toujours… avec le programme "instable" !
[^] # Re: Conservatisme
Posté par THE_ALF_ . Évalué à 2.
Le package ffmpeg 1.0 est dispo sur http://www.deb-multimedia.org/ , si je ne m'abuse.
Donc les 2 paquets sont accessibles facilement. Certes, debian multimedia ne fait pas partie de la branche debian officielle, mais y est très bien intégrée. Bref, on a le choix.
[^] # Re: Conservatisme
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
Attention quand même avec deb-multimedia. Je ne sais pas comment ça se passe en stables, mais en sid, j’ai eu pendant longtemps des problèmes de dépendances, d’applications multimédia qui plantaient. Jusqu’au jour ou suite à un rapport de bug, je m’aperçoive que tout cela venait de deb-multimedia, résultat, 2 jours de dpkg --force pour arriver à nettoyer tout le merdier…
Et depuis, je n’ai plus de problèmes. (cf. http://wiki.debian.org/DebianMultimedia/FAQ)
[^] # Re: Conservatisme
Posté par THE_ALF_ . Évalué à 2.
Comme toujours, lorsque l'on prends à partir de repository non-officiels, il faut être cohérent et faire attention lorsque des packages peuvent être présent dans différentes version à différents endroits. Aucun problème si on a bien un ensemble de package multimedia de la même source (i.e. mplayer).
[^] # Re: Conservatisme
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
Ça devient compliqué lorsque les paquets dans un dépôt induisent une chaîne de dépendance qui va affecter les méta paquets permettant l’installation différents gestionnaires de bureau et que le dépôt en question s’arrange pour que ses paquets soient systématiquement prioritaires sur les versions « officielles » en bidouillant des numéros de versions…
[^] # Re: Conservatisme
Posté par freem . Évalué à 2.
Lu sur wikipedia :)
En gros, tu colles une version en développement, nommée unstable, avec des paquets provenant d'une source externe…
J'admets utiliser unstable, mais pas tout seul (je garde un maximum de testing) je fais quand même gaffe lors des mises à jour, il n'est pas rare (ni commun, c'est juste que ça arrive) qu'un paquet casse mon système lors de la mise à jour… et les paquets qui ne viennent pas d'un dépôt officiel, je vérifie en quoi consistent les changements, et si j'en ai vraiment besoin…
# Attention: postgresql
Posté par Loïc Blot (site web personnel) . Évalué à 10. Dernière modification le 05 mai 2013 à 11:09.
Petite note à ceux qui vont passer de PostgreSQL 8.4 à 9.1: la modification de version de postgresql implique d'exporter toute votre DB et de réimporter l'ensemble une fois l'upgrade fait. Contrairement à MySQL PostGreSQL change son support de données entre les versions.
Donc:
Mise à jour puis
Veepee & UNIX-Experience
[^] # Re: Attention: postgresql
Posté par wismerhill . Évalué à 10.
Ou alors, on profite du travail fait par les mainteneurs qui s'occupent de postgresql dans debian:
- On installe la nouvelle version à côté de l'ancienne (comme le permettent les paquets debian), c'est automatique si on a installé le méta-paquet non-versionné postgresql
- On utilise le script pg_upgradecluster qui va se charger de créer un nouveau cluster dans la nouvelle version et d'y copier toutes les données, sans devoir passer par un fichier temporaire.
[^] # Re: Attention: postgresql
Posté par wilk . Évalué à 2.
A propos de postgresql et du multi-architecture, est-ce qu'il est du coup possible d'installer deux versions d'architectures différentes ? Ce serait vraiment pratique pour pouvoir répliquer des bdd venant de machines de différentes archis !
Et est-ce qu'en utilisant apt.postgresql.org on bénéficie également de cette multi-architecture ?
[^] # Re: Attention: postgresql
Posté par jihele . Évalué à 3.
La dernière fois que j'ai fait ça, pour une mise à jour mineure, j'ai eu un petit problème.
Le script de mise à jour est chargé d'arrêter le vieux cluster, mais chez moi, il n'y parvenait pas. Je pouvais l'arrêter moi-même avec l'option --force, mais il faut que le script le fasse lui-même parce qu'il a des choses à demander au cluster avant. En gros.
J'ai donc modifié /usr/bin/pg_upgradecluster pour remplacer le timeout par un force:
et ça a fonctionné.
Le script de mise à jour a été modifié pour pouvoir fonctionner avec un cluster arrêté (il le redémarre avec une connexion restreinte). Ça permet de l'arrêter à la main avec --force avant, dans le cas où le script n'y arrive pas avec l'option timeout.
Voir ce rapport de bogue : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681344
La version de postgresql-common qui contient cette modif (la version 135) n'est pas encore dans Wheezy : http://packages.qa.debian.org/p/postgresql-common.html
[^] # Re: Attention: postgresql
Posté par kadalka . Évalué à -6.
Et c'est tout ?
(Parce que je ne savais pas que c'était si simple)
[^] # Re: Attention: postgresql
Posté par wismerhill . Évalué à 3.
Avoir beaucoup de temps devant soi, car plus le cluster est volumineux plus ce sera long (mais ça, c'est pareil avec la méthode classique du dump puis ré-import).
Et vérifier après coup que la configuration du nouveau cluster est bien correcte et s'il n'y a pas quelques petites choses à adapter pour la nouvelle version.
Sinon, oui, quand j'avais mis à jour des serveurs de lenny vers squeeze (donc de PG 8.3 vers 8.4) ça avait été aussi simple que ça, et c'était une bonne surprise, car à l'époque j'avais commencé à préparer la migration telle que conseillée dans la doc de PG (avec l'avantage tout de même d'avoir les deux version installée en parallèle), puis au hasard d'une complétion du shell j'avais repéré cette cette commande pg_upgradecluster qui m'a bien simplifié la tâche.
[^] # Re: Attention: postgresql
Posté par Graveen . Évalué à 2.
Merci Nerzul. J'allais grave passer à côté !
# Aujourd’hui !
Posté par Thom (site web personnel) . Évalué à 3.
Je passe sous debian pour mon usage personnel aujourd'hui.
J'avoue avoir eu un peu peur des périodes de gel alors je suis passé sous sid directement après l'installation de testing.
J'ai plus qu'à bidouiller un peu pour retrouver un système qui me convienne entièrement.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Aujourd’hui !
Posté par barmic . Évalué à 5.
Moi j'aime bien la stable. J'utilise des backports et des trucs ne plus mais dans l'ensemble c'est du stable qui tourne.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Aujourd’hui !
Posté par claudex . Évalué à 10.
Sid subit aussi la période de gel.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Aujourd’hui !
Posté par freem . Évalué à 4. Dernière modification le 06 mai 2013 à 12:41.
Le seul dépôt à ne pas être affecté par le gel est "experimental", mais malheureusement, il ne s'agit pas d'une distro complète, et en plus il faut jouer avec les priorités (/etc/apt/preferences) pour qu'ils s'installent automatiquement.
Donc, sid à aussi été gelé, désolé de te décevoir… d'ailleurs j'ai trouvé le gel très long, et je suis bien content que ce soi fini.
L'hiver aura été long et rigoureux à la fois IRL et chez Debian cette année :D
# MTA 0.68.2 ?
Posté par Kioob (site web personnel) . Évalué à 5.
Pour ceux qui se demanderaient quel paquet / logiciel se cache derrière MTA 0.68.2 annoncé ci-dessus, il s'agit en fait de Courier MTA ; comme indiqué dans les notes de publication.
alf.life
# multiarch
Posté par Troy McClure (site web personnel) . Évalué à 6.
C'est un peu triste mais depuis le passage au multiarch c'est devenu plus dur de cross-compiler du i386 sur une debian amd64. Il y a trop de paquets qui ne peuvent être installés simultanement pour les deux architectures , par exemple libfreetype6-dev:i386 et libfreetype6-dev:amd64 , en gros c'est une regression par rapport au bon vieux paquet ia32-libs-dev qui offrait tout le necessaire sans prise de tete .
[^] # Re: multiarch
Posté par barmic . Évalué à 1.
Tu as remonté le problème à Raphaël Hertzog ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: multiarch
Posté par Troy McClure (site web personnel) . Évalué à 3.
Il a été remonté: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666761
# Merci et Bravo
Posté par cveyoda (site web personnel) . Évalué à 6.
Bonsoir,
Je ne dirais qu'une chose "merci et bravo" à tout les participants :) .
# Grub2
Posté par geb . Évalué à 3.
Géniale cette dernière debian … sauf que grub ne veut plus s'installer avec le support du raid mdadm + lvm … le core.img est trop gros pour tenir dans le MBR. Il y a plus de stage 1,1.5,2 ?
Pour ceux qui voudraient l'installer, pensez à laissez quelques Ko avant vos partitions, ça vous évitera bien des galères..
[^] # Re: Grub2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Et si vous partitionnez en GPT et démarrez en BIOS, sachez qu'il n'y a plus d'espace intersticiel où GRUB pourrait aller se loger entre la table des partitions et la première partition : il faut créer une partition dédiée à GRUB, de type BIOS boot partition. Si vous démarrez en UEFI, GRUB se mettra sous la forme d'un fichier dans votre partition système EFI.
[^] # Re: Grub2
Posté par GG (site web personnel) . Évalué à 1.
Bonjour,
comment tu l'as découvert? est ce que l'on a un message d'erreur explicite ou pas?
La dernière fois que j'ai voulu installer Grub dans ce cas, je n'avais qu'un message me disant que cela avait échoué, sans plus de précision.
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Grub2
Posté par geb . Évalué à 3.
En lançant un grub-setup /dev/sda depuis un chroot du système on a un peu plus de détails sur les messages.
[^] # Re: Grub2
Posté par neil . Évalué à 4.
Je viens de faire une installation de wheezy en mdadm+lvm (raid1) entièrement via l’installeur du cd netinstall (avec partitionnement dans le même installeur), et je n’ai eu absolument aucun soucis ni aucun message d’erreur. Ça serait cool d’avoir le rapport de bogue qui correspond à ce dont tu parles pour qu’on puisse comprendre quelles sont les conditions du problème.
[^] # Re: Grub2
Posté par geb . Évalué à 0.
i386 ou amd64 ? J'étais en amd64
Je vais faire un vrai rapport de bug des que je trouve le temps..
[^] # Re: Grub2
Posté par roychris . Évalué à 2.
Si les partitions ont été faite avec fdisk sur squeeze, le problème est présent. Mais grub-install indique clairement le problème.
fdisk sur wheezy prévoit automatiquement de l'espace libre avant la première partition ce qui ne posent plus de problèmes.
Le premier secteur utilisé avant (squeeze) était le 64, c'est le 2048 maintenant (wheezy).
J'ai eu de la chance de répartir les swap au début de chaque disque de mon raid, car j'ai juste eu besoin de supprimer les swap un par un et de les recréer sous wheezy pour que le grub-install passe.
[^] # Re: Grub2
Posté par neil . Évalué à 2.
Amd64. Comme dit roychris, mes partitions formatées depuis le cd d’install commencent en 2048. Ça laisse de la place pour les 32k du core.
[^] # Re: Grub2
Posté par ariasuni . Évalué à 0.
Si j’ai bien compris tu fais du RAID pour de la swap? Parce que si j’ai bien tout compris ce que j’ai lu ci et là, c’est inutile car tu peux avoir plusieurs swap et Linux (le noyau) est assez malin pour gérer ça de façon optimale.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Grub2
Posté par roychris . Évalué à 0. Dernière modification le 11 mai 2013 à 08:08.
Tu as mal compris :)
Plutôt que de mettre 1 swap sur un disque, j'ai bien 3 swaps sur 3 disques. Mais qui ne sont pas sur le RAID.
J'ai donc 2 partitions sur chaque disque : le swap et le raid md. Après j'ai lvm pour repartitionner le reste.
[^] # Re: Grub2
Posté par ariasuni . Évalué à 1.
C'est pas trop galère le LVM? Parce que j'ai jeté un œil et franchement ça me paraissait légèrement compliqué si on veut juste faire deux partitions.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Grub2
Posté par claudex . Évalué à 5.
C'est 4 commandes pour créer deux partitions, ce n'est pas si compliqué que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Grub2
Posté par Kioob (site web personnel) . Évalué à 3.
Mouais, le kernel est suffisamment malin pour faire du «stripping» sur les volumes swap, et donc le RAID0 est effectivement inutile. Par contre (à ma connaissance) il ne gère aucune redondance, donc si un des disques flanche complètement, tu perds les données actuellement en swap, c'est à dire que certaines applis risquent fortement de crasher.
Sur du desktop c'est peut-être suffisant, mais sur un serveur je ne suis pas prêt à prendre ce risque.
alf.life
[^] # Re: Grub2
Posté par Prosper . Évalué à 3.
Il est fortement conseillé de mettre le swap sur le raid, pour la simple et bonne raison que si t'as 2 swaps sur 2 disques différents , et qu'un disque crash, tout le système crash (testé et approuvé)
[^] # Re: Grub2
Posté par roychris . Évalué à 1.
Une indisponibilité du système qui dure le temps d'un reboot est pour mon utilisation acceptable, et le gain en rapidité en répartissant le swap sur deux disques me parait intéressant, d'où mon choix !
[^] # Re: Grub2
Posté par GG (site web personnel) . Évalué à 4.
Le système qui crash, ça signifie : perte de données, écritures non terminées ou alors des données incohérentes… plus éventuellement le temps de vérification des données alors que le RAID se reconstruit avec le disque de spare.
Je préfère avoir une alerte, et que le système continue comme si de rien n'était, les données toujours cohérentes.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Grub2
Posté par ariasuni . Évalué à 3.
Tu m’as convaincu de mettre un RAID 1 sur mes partitions de swap… Par contre je me demande de quel ordre sont les pertes de performances?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Grub2
Posté par Kioob (site web personnel) . Évalué à 2.
C'est 2 fois plus lent. Le swap sur HDD est terriblement lent, à la limite du supportable. Que ce soit en RAID1 ou RAID0 n'y change vraiment pas grand chose…
alf.life
[^] # Re: Grub2
Posté par GG (site web personnel) . Évalué à 2.
Le serveur qui commence à swapper, c'est mauvais signe.
Tout se ralenti, et cela peut l'entraîner dans une spirale infernale. Il met plus de temps pour effectuer le travail, qui peut s'accumuler etc.
En tout cas, la swap sert quand il n'y a pas assez de ram (grosso-modo), c'est un peu comme une sorte de cri de détresse. Il faut revoir les réglages des applications, ou augmenter la ram.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Grub2
Posté par claudex . Évalué à 4.
Je pense qu'il parlait des performance de mettre la swap en RAID par rapport à 2 partitions de swap.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Grub2
Posté par ariasuni . Évalué à 1.
Effectivement, je ne pense quand même pas que ça soit de l’ordre de la moitié mais j’imagine bien que ça doit être assez lent par rapport à l’utilisation sans RAID…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Grub2
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
En même temps, la spirale infernale, avec Debian, c'est normal !
# AdGate²
Posté par olaf . Évalué à 3.
J'ai déjà plusieurs serveurs en wheezy qui tournent sans problème mais je ne l'avais pas essayée en "Workstation".
Tout se passe bien, on reste sur un terrain plus que connu lors de l'installation. Ma surprise arrive lors de la première ouverture de Iceweasel sous X, celui-ci m'indique de adblock a bien été installé et m'invite à le configurer…
C'est sympa, mais je l'aurai fait moi-même si je l'avais souhaité…
[^] # Re: AdGate²
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Ça c'est le méta-paquet gnome qui dépend visiblement de xul-ext-adblock-plus.
# Migration 32 bits => 64 bits avec multiarch
Posté par Xavier Poinsard . Évalué à 4.
Je me demande si avec le multiarch, il va être possible facilement de migrer de 32bits vers 64bits…
Des idées ou retours d'expériences ?
[^] # Re: Migration 32 bits => 64 bits avec multiarch
Posté par freem . Évalué à 1.
Je n'ai pas testé, mais je pense que tu pourras au moins switcher facilement vers 64bit.
Pour ce qui est de supprimer l'archi 32bit par contre, personnellement je n'ai pas réussi quand j'ai voulu installer, puis supprimer wine et skype (alors que j'étais de base en 32 bits).
Après, franchement, je risquerais pas un système fonctionnel sur une telle mise à jour… le multi arch est quand même quelque chose d'assez jeune, après tout.
[^] # Re: Migration 32 bits => 64 bits avec multiarch
Posté par snurpsss . Évalué à -1.
Je me suis posé la même question: voyant la release sortie, je me suis dit que c'était le bon jour pour passer en 64 bits, mais me retrouvant bloqué sur la désinstallation du driver graphique / l'installation des pilotes Nvidia à la mano (depuis le .run fournis sur le site officiel), je me suis dit que j'étais une bonne buse, et voulant un truc qui marche, j'ai remis une bonne vieille version i386 (où j'ai très simplement installer les drivers proprio via le .run).
J'ose même pas imaginé m'être pris la tête pendant 2h pour faire fonctionner les drivers proprio Nvidia sous 64 bits, pour me retrouver sans flash ou sans skype.
Du coup, j'attend des retours de la multiarche pour savoir si ça vaut le cout de s'embêter avec ça…
[^] # Re: Migration 32 bits => 64 bits avec multiarch
Posté par freem . Évalué à 4.
Bah, skype, flash, wine et nvidia marchent aussi bien sous 64 que sous 32.
J'utilise multi-arch quotidiennement depuis que ça existe chez debian (suis en testing/unstable en permanence), et je n'ai jamais rencontré de problème de fonctionnement lié à ça (par contre je me suis retrouvé incapable de virer l'arch i386 de mon netbook quand j'ai enlevé skype, préférant ne mettre le bordel que sur une seule machine sur laquelle je prend le controle via ssh).
Quoique pour nvidia, j'utilise le paquet fournis par la distro, ça m'évite les emmerdes… que tu sembles d'ailleurs rencontrer.
Par contre, je ne sais pas si la version des dépôts debian est à jour: sur debian packages il semble que ce soit la 304.88 quand le site de nvidia semble suggérer le 314… mais au moins la MaJ est automatique.
[^] # Re: Migration 32 bits => 64 bits avec multiarch
Posté par Maderios . Évalué à 1.
J'ai été en wheezy 64 bits puis maintenant testing 64 bits. Je n'ai jamais utilisé les paquets debian Nvidia. Driver Nvidia proprio téléchargé et installé lors de chaque sortie de nouvelle version. Si on veut passer en 64 bits sans problèmes, ne pas installer multiarch, mais passer directement en amd64. Ensuite on peut installer multiarch, si nécessaire seulement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.