Que ce soit libre, c'est mieux.
Mais que le principe puisse faire tout ce Pataquès me sidère.
J'en ai rien à foutre que quelqu'un sache si je suis vacciné ou pas. C'est d'autant plus débile que si tu vas à un rassemblement de plus de 1000 personnes, on sait que t'es vacciné.
Y a une paranoïa de taré actuellement.
La librairie libasound est toujours utilisée, et par pipewire aussi.
Il y a seulement la partie "traitement du signal" (mixage, filtrage, etc) de Alsa qui n'est plus utilisée car redondante (avec pulse, jack et pipewire).
J'ai installé F34 depuis le premier jour de la Beta. Aucun problème notable alors que je l'utilise tous les jours. En fait j'utilise Fedora quasi tous les jours depuis des années.
Je n'ai pas remarqué le changement de logo. J'ai remarqué un changement cosmétique donc anecdotique. En même temps, on le voit peu !!!
Juste pour dire que je ne comprends pas qu'il soit l'objet d'une polémique vive.
Le changement lié à grub.cfg est un peu expliqué dans cette dépêche, mais j'y reviens car je me suis fait "avoir".
J'ai dû refaire mon grub.cfg, donc j'ai tapé "grub2-mkconfig > /boot/efi/EFI/fedora/grub.cfg".
Je reboote, tout marche comme prévu, aucun de problème.
Il faut noter que sur Fedora (et probablement bien d'autres), sauf changement majeur, on n'a pas à faire de grub2-mkconfig, grub.cfg ne change plus même quand on installe un noyau ou on change les paramètres de boot (cf /boot/loader).
Mais j'ai vu plus tard que le "vrai" grub.cfg n'est pas sur la partition /boot/efi, mais sur la partition /boot (ou / si vous n'avez pas de /boot comme moi).
Voila le contenu de /boot/efi/EFI/fedora/grub.cfg :
search --no-floppy --fs-uuid --set=dev 8213e1e1-66aa-4afa-aadc-3d6b0f8b5dec
set prefix=($dev)/boot/grub2
export $prefix
configfile $prefix/grub.cfg Sauf pour définir /boot (ou /), /boot/efi/EFI/fedora/grub.cfg ne sert plus à rien.
Cela présente un avantage. Imaginons que /boot/efi soit sur /dev/sda? et /boot (ou /) sur /dev/sdb? . Si /dev/sda est mort, il vous suffit d'avoir un boot grub (par exemple sur une clé USB) et de faire un configfile (hd…)/grub2/grub.cfg. (ou /boot/grub2/grub.cfg).
Je trouve que c'est un bon changement car l'OS est moins dépendant de la partition de boot EFI.
En passant.
Pipewire, dont il y a vraiment peu de doc utilisateur voire pas du tout (c'est fort dommage), ne remplace pas Alsa, ou alors qu'une petite partie. Les drivers audios sont uniquement dans Alsa.
TousAntiCovid est est open source.
Et franchement, à moins, et peut-être, d'être un opposant, l'État en a rien à foutre de nous individuellement.
Imaginons que je trompe ma femme et que TousAntiCovid permet de le savoir, l'État s'en torche le fion.
TousAntiCovid n'est pas obligatoire et ne le sera pas, il rendra les choses plus pratique seulement.
L'État n'a AUCUN intérêt à bloquer ou limité l'économie.
Puis les thèses complotistes sur TousAntiCovid par des personnes qui utilisent une CB, un téléphone, facebook, un IP connue d'un fournisseur d'accès, etc. LOL quoi.
Faut arrêter avec les "systemd fait tout".
Systemd ne fera pas traitement de texte, pas serveur web, pas gestionnaire de base de données, etc.
En chiffre.
Le src.rpm de systemd fait 10Mo. L'ensemble des src.rpm de f34 fait 58Go.
Donc systemd c'est 0,017 % d'une Fedora. Ce sont des chiffres pour donner un ordre de grandeur, rien de plus. Sur un installation desktop minimum (par exemple le profil "Fedora Workstation" sans rien de plus), ça doit faire maxi 0,5%. Si systemd faisait tout, on se passerait des 99,5 % qui constitue le "reste".
Le problème des services utilisateurs est qu'il doivent être gérés.
Cas plus intéressant, les démons utilisateurs qui ne doivent être là que lorsque la session est ouverte.
Avec systemd, on est sûr qu'à la fin de la session le service utilisateur est tué. On peut aussi être sûr qu'il va être relancé s'il plante. On est sûr qu'il est comptabilité dans les ressources (dont la mémoire), etc. S'il y a des dépendances, systemd le gère.
Il est donc complètement normal que systemd le fasse. Et ça sera plus fin. Avec SeLinux, il sera aussi vérifié que cette appli ne se connecte pas partout, etc.
Cet aspect utilisateur de systemd ne fait que commencer. On pourra à l'avenir, en étant utilisateur, télécharge des applis tiers, qui ne sont pas de confiance, et les faire tourner sans risque (plus besoin comme aujourd'hui de créer un compte séparé ou un container, etc). Quand on arrête l'appli, on est sûr qu'elle est arrêtée. Ce qui avant était loin d'être évident…
Quand on comprend le rôle de systemd, on comprend qu'il n'est pas là pour tout faire. Évidemment, certains diront que tel ou tel truc pouvait ne pas être dans systemd. Ya toujours des exceptions pour confirmer la règle.
En passant sur Fedora 33, je suis passé à btrfs, c'est le fs par défaut pour le profil "Workstation".
J'ai survolé les caractéristiques de btrfs et ça n’excitait pas mal. Les snapshots et les volumes logiques qui partagent un même volume physique (j'ai oublié les termes techniques).
Puis j'ai creusé un peu la doc de btrfs. J'ai vu 2 défauts (pour moi).
Désolé mais j'ai oublié un des défauts (je crois que c'est lié au raid où les perfs ne sont pas toujours au niveau attendu, mais c'est un peu accessoire ici).
Le gros défaut (pour moi hein) est que btrfs ne gère pas les "badblocks". Il m'est arrivé d'avoir des disques avec quelques secteurs défectueux et qui marchent encore durant des années. Évidemment, si les données sont précieuses, on peut bien casquer pour avoir des disques sans secteurs défectueux. Surtout que les disques sont peu chers (sauf si on stocke du lourd genre beaucoup de vidéos).
Bref, je suis retourné à ext4. Formatage et tout, un peu pénible de refaire ce qu'on vient faire.
Je ne dissuade pas d'utiliser btrfs qui est un bon fs avec des fonctionnalités très alléchantes. Surtout que les SDD, de plus en plus courants, gèrent eux-même les badblocks.
Je donne cette info car j'ai remarqué qu'elle était pas très connue et que j'étais très surpris de constater ce manque.
Ces spécificités debian dont tu parle sont presque de l'histoire ancienne. Tout ce qui est arrivé et n'a pas plus (PAM, pulseaudio, systemd, network-manager, dbus, wayland,…) font de linux une plateforme simplifiant la vie de ces "projets qui ne s'intéressent pas qu'à linux"® parce qu'ils n'ont pas à supporter les spécificités des n distributions * les m versions de chacune encore en court.
Toutes ces spécificités à Linux (systemd, cgroup, etc) n'intéressent que ceux qui en ont besoin. Ce n'est pas parce que je fais un programme pour Linux que j'ai besoin d'utiliser ce qui est spécifique à Linux.
Mais si je veux faire un service (pas qu'un processus) qui par exemple a un quota pour la mémoire, je ne peux le faire qu'avec Linux et cgroupv2 (qui lui exige Systemd). Ou un firewall sur les services et pas que port/adresse, là encore il faut cgroupv2. L'autre dira qu'il s'en fout…
Si je veux faire un service qui demande un id user dynamique (des sortes de compte utilisateur créé à la volée), je peux le faire avec Linux (et je crois, mais pas sûr, que ça exige Systemd).
Personne ne fait du spécifique Linux sans raison.
Quand on regarde les gros programmes comme httpd, postgresql, etc, ils ont quasi tous du code spécifique pour Linux. Ils pourraient l'enlever, mais ça sera moins bien sur Linux. Et ils font la même chose pour FreeBSD, etc.
Le système d'init n'impacte pas le logiciel aussi profondément que tu le sous-entends. Tous ses logiciels n'ont pas cessé de fonctionné avec l'arrivé de systemd.
Cela a toujours été l'intention de Systemd. Tous les anciens programmes doivent marcher avec Systemd, rien ne doit être cassé (sauf quelques fichiers init qui ne sont pas pris en charge mais il y a des solutions pour ça).
Je n'ai pas dit que tous les nouveaux marcheront avec l'ancien init.
Gnome si on veut tous ses fonctionnalités demande systemd. Idem pour udisks, etc.
Après, si tu veux troller sur systemd, il s'agit d'un système d'init parmi plein d'autre.
C'est quand même gonfler de dire que je trolle alors que c'est vous qui trollez.
Et là encore avec un "init parmi plein d'autres". Si c'était le cas, certains n'en auraient pas fait un gros caca. Si c'était le cas, on se demande pourquoi vous en parlez sans qu'on vous le demande.
Systemd ? Bah on s'en fout, comme on se fout que tu préfères utiliser Lyx, Abiword, Calligra, OpenOffice, Libreoffice, ou que-sais-je.
Quand vous vous foutez de quelqu'un, faites le avec "finesse".
Vous vous en foutez, mais il y a 6 fois "systemd" dans votre post. C'est très cohérent. Hein?
Ce dont on ne se fout pas, c'est simple : si tu veux tu peux, si tu ne veux pas tu peux ne pas.
Ah bon ?
Donc il fallait dire dès le début : "si vous voulez SystemD ou autre, vous pouvez".
Mais ce n'est pas votre choix. Vous avez dit "tout le monde s'en fout".
Donc la vous expliquez que Slack donne une possibilité dont tout le monde se fout ?
Vous êtes tordu.
Et… tous les auteurs de logiciels qui ne font pas leurs logiciels exclusivement pour Linux ne font pas leurs logiciels exclusivement pour systemd.
Bravo, vous avez enfoncé une porte ouverte. J'espère que votre épaule ne vous fait pas trop mal pour ça.
Parce qu'il n'y a pas que Linux dans la vie
J'avais écrit : "En général les auteurs de logiciel font des programmes pour des OS, voire le dénominateur commun des OS."
PS : le troll sur UTF8, j'ai pas pigé…
https://docs.slackware.com/slackware:localization
" Note that Slackware is not fully Unicode-prepared. Some applications (like the man pages) will not properly display Unicode text. For some languages (in particular the non-Latin ones) it is mandatory to enable Unicode support (see further down) or else the character glyphs will not be displayed (you will see nothing but small rectangles instead)."
Unicode n'est toujours pas par défaut.
Ceci dit, je m'en fous, j'utilise pas Slack.
Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.
Typiquement, lors de la sortie de la 14.2, systemd c'était pas encore le truc à la mode.
Le truc à la mode ?
Il y en a qui ne veulent pas de systemd, très bien, ils font comme ils veulent. Mais ce type d'argument est stupide.
Personne ne t'a forcé la main en tout cas, et tu n'as pas eu à changer tes habitudes en 5 ans.
Là je ne peux pas dire que l'argument est stupide, mais il est douteux.
Peut-être disiez vous la même chose pour PAM, puis UTF8, PulseAudio, etc.
Toutes ces choses où finalement SlackWare vous a "forcé la main".
Qu'en sera-t-il pour Systemd ?
Personne ne force personne. Ce qui veut aussi dire que vous ne pouvez pas forcer les développeurs à ne pas passer à Systemd s'ils le souhaitent.
Il y a des conservateurs qui ne veulent pas suivre le "progrès" (<= guillemets), parfois ils ont raison, parfois tort.
la 15.0 sera aussi sans systemd, parce que tout le monde s'en fout de systemd
Tout le monde s'en fout ?
Carrément.
J'suis comme Imarcini, j'ai commencé avec une Kheops, avec une Slack quoi. C'était en 95 (linux 1.2, sans module, ça ne nous rajeunit pas…), donc le vieux système init j'en ai bouffé durant des années puisqu'il n'y avait que ça. Puis est arrivé Systemd, un petit délai d'adaptation, et je ne regrette pas du tout le système init, pas du tout du tout. Je ne dis pas que c'était de la merde, mais que je n'ai aucune "nostalgie".
systemd casse le principe fondamental de dire qu'un paquet Slackware s'installe et se paramètre comme les auteurs du logiciel l'ont prévu.
Et pour ceux qui n'ont pas prévu le système init (à l'ancienne), ce n'est donc pas sur Slack ?
Systemd est plus simple pour les développeurs. Il est maintenant plus répandu, donc peut-être qu'à terme certains développeurs upstreams ne feront plus de script init (entre autre car ils n'ont pas de distribution pour les tester). Si des "Slackeux" veulent faire un patch (upstream ou pour la Slack), c'est génial, ça ne me pose aucun soucis.
En général les auteurs de logiciel font des programmes pour des OS, voire le dénominateur commun des OS. Si les OS changent, ils s'adaptent. Ils sont forcément en retard. Je ne critique pas, je dis que ça ne peut être qu'ainsi pour la majorité des développeurs. Qu'ils soient en retard n'indique pas que les évolutions de l'OS sont mauvaises.
Posté par Pseudo007 .
En réponse à la dépêche Fedora 31 est sortie !.
Évalué à 4.
Dernière modification le 01 novembre 2019 à 08:31.
Ah la résistance au changement…
Le menu.lst que tu édites à la main (donc que le système ne devrait pas gérer) est maintenant : /etc/grub.d/40_custom
Le gros problème de menu.lst, est qu'il est édité par l'utilisateur et le système. 40_custom est géré que par l'utilisateur.
Est-ce que le menu.lst gérait les échecs de boot pour proposer un mode "sans échec" ? Je ne crois pas.
Est-ce qu'il gère le boot par défaut "automatiquement" ? Je ne crois pas.
Je donne un exemple concret d'avantage pour moi de Boot Loader Specification.
J'ai plusieurs disques durs sur mon système. Un disque est le boot "habituel", un autre un backup (typiquement hebdomadaire avec rsync). Si le boot habituel ne marche pas, je boote sur le backup.
Avant à chaque backup je devais éditer grub.cfg (c'est fait par script avec des sed). Maintenant je n'ai rien à faire. Évidemment que je dois toujours copier /boot (pas /boot/efi), mais c'est tout. Et il ne faut pas oublier que /boot n'a pas forcément à avoir sa propre partition, ça peut être la partition racine (ce qui est le cas chez moi).
Posté par Pseudo007 .
En réponse à la dépêche Fedora 31 est sortie !.
Évalué à 4.
Dernière modification le 31 octobre 2019 à 13:43.
(c'est uniquement pour vous mettre l'eau à la bouche)
Ce n'est pas une nouveauté f31, mais f30 ou f29, que j'ai raté car je suis passé de f29 à f31 (oui c'est mal).
Quand on ajoute un noyau à son GNU/Linux chéri, vous savez comment ça se passe, il faut changer grub.cfg. C'est fait, sous Fedora, par une usine à gaz nommée grubby. Si c'est automatisé et que les programmes font bien leur job, ce n'est pas vraiment souci. Mais si vous ajoutez à la main un noyau, etc.
Comment ça marche concrètement ?
Si j'ajoute un noyau (avec son initrd) à ma machine, il me suffit de déposer un fichier qui décrit ce noyau dans /boot/loader/entries/ . Le nom du fichier doit être machineId_CeQueVousVoulez.conf. machineId est à récupérer de /etc/machine-id.
Exemple de fichier :
$ cat /boot/loader/entries/16218b18041341aa845c9ed438f5c154-5.3.7-301.fc31.x86_64.conf
title Fedora (5.3.7-301.fc31.x86_64) 31 (Thirty One) version 5.3.7-301.fc31.x86_64
linux /boot/vmlinuz-5.3.7-301.fc31.x86_64
initrd /boot/initramfs-5.3.7-301.fc31.x86_64.img
options $kernelopts
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
Si vous supprimez le noyau, il vous suffit de supprimer le ficher pour qu'il n'apparaisse plus dans grub lors du boot.
Un lecteur attentif aura remarqué qu'on n'a pas tout pour pouvoir booter, notamment il manque la partition root. Quand on ajoute un noyau, on ne change pas de root, donc l'information n'a pas à être dans ce fichier. Néanmoins c'est récupéré dans la variable $kernelopts qui est définit dans grub.cfg.
Dans mon grub.cfg j'ai :
set default_kernelopts="root=UUID=033fead8-f5bf-4433-a108-74c7359b96c1 ro rd.md.uuid=8ac3b7b8-1bc9-7973-15a8-1361718c00ae"
Comment grub prend en compte les fichiers dans /boot/loader/entries ?
Il le fait lors du boot et va créer "à la volée" une entrée grub classique (qu'on pourra éditer avec grub au boot si nécessaire) genre :
menuentry 'Fedora 31' ... {
set root=...
linux /boot/vmlinuz-... root=...
initrd /boot/initramfs-...
}
C'est demandé dans le fichier grub.cfg par :
insmod blscfg
blscfg
Et voilà !
C'est une petite chose mais je suis ravi de le voir car avant c'est vraiment "hugly".
Fedora Toolbox est un petit utilitaire bien pratique.
Il crée une sorte de chroot mais on conserve son home. Il ne demande pas d'être root même pour y installer des paquets. C'est à moitié vrai, on fait "sudo ou su" sans avoir à rentrer de mot de passe. Tout est dans $HOME ($HOME/.local/share/containers). Depuis ce chroot on peut aussi lancer des applis graphiques.
C'est très simple d'emploi. Idéal pour un environnement de développement où on peut être amené à installer plein de paquets. Ainsi ça évite de "saloper" son OS principal. Si on fait tout son boulot dans $HOME comme il se doit, il n'y a rien à sauvegarder, c'est le $HOME principal (on peut détruit le container, rien est perdu). https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
Très cool.
PS: je ne sais pas ce qu'il y a sous le capot (je le devine un peu néanmoins).
J'ai installé aujourd'hui.
Anaconda ne m'a pas rassuré, j'ai dû faire plusieurs essais (il se plaignait des partitions qui devraient être GPT alors qu'elles le sont déjà et je ne sais quoi d'autre avec UEFI). Finalement, et je ne sais comment, mais cela a marché après plusieurs tentatives. J'ai un système avec 6 disques, mais ce n'est pas une excuse, cette partie de l'installeur doit être bétonnée. Avant d'arriver sur la page principal de l'installeur, on passe sur un écran où on choisi la langue, puis un écran pour le réseau. Pour ce deuxième écran le clavier n'est pas configuré. Je ne comprenais pas pourquoi je n'arrivais pas à me connecter à mon wifi, le mot de passe n'était pas le bon (NB: pas d'option d'affichage du mot de passe pour savoir ce qu'on tape et pas d'autre champ pour faire un essai). Vu qu'on peut configurer le réseau plus loin, avec le clavier configuré (et aussi voir le mot de passe), ce n'est pas très gênant.
Tout le reste va presque pour le mieux dans le meilleur des mondes sauf peut-être un réglage de la vm ou cache disque qui rend le système quasi inutilisable lorsque je fais des grosses copies de fichiers et que le cache est "sous pression" (je débite entre 200 et 300 Mo/s sur mon maintenant vieux i7). C'est beaucoup mieux lorsqu'on vire le swap (j'ai assez de mémoire pour le faire). Petit désagrément pour les consoles textes, elles ne prennent pas tout l'écran. Toujours le même problème de l'interface Firefox en anglais.
Tout le reste a bien marché "out of the box". Le DAC reconnu et utilisé par défaut, casque Bluetooth nickel, pas de soucis avec rpmfusion, etc.
Ce n'est plus la même excitation qu'il y a quelques années. Le système évolue peu, il se peaufine. Je ne m'en plains pas.
J'ai F25 depuis 1 mois (évidemment via un passage par la version beta).
Utilisation du bureau Gnome/Wayland.
Wayland fait perdre quelques fonctionnalités, mais rien d'important. En fonction des besoins, ça peut être irritant. Donc fournir X11 est nécessaire encore et peut-être pour assez longtemps.
Wayland chez moi est "rocksolid". Avec Xorg j'avais parfois des plantages, aussi des soucis avec gnome-shell quand utilisation de libva (vaapi). L'affichage en 3D de http://flightradar24.com/ dans Firefox faisait parfois planter Xorg. Avec F25 je n'ai eu absolument aucun problème de fiabilité avec Wayland ! Rien, nada. Chapeau bas !
Je suis convaincu que la grande majorité des utilisateurs de Gnome seront sous Wayland avec F25.
Avant j'avais F23, mais il restait trop de limitation pour utiliser en permanence Wayland (à l'époque déjà rocksolid).
Le problème le plus irritant que j'ai avec Wayland est qu'un "su -l" (ou sudo) ne configure pas l'environnement pour utiliser Wayland (il faut utiliser xhost et définir $DISPLAY à la main). C'est bien un bug de l'intégration de Wayland. Je précise qu'il reste des défauts, mais ils sont anecdotiques.
Pour le reste, ben j'ai rien à dire, tout marche comme prévu, désolé.
Dans les très nombreuses versions de Fedora que j'ai utilisé (je suis sous Fedora depuis le début de Fedora), c'est celle qui a la meilleure qualité. Après de mémoire ça devait être la version 13 ou 15.
Le seul moment où j'ai fait un peu de recherche car j'avais un problème était avec mock. Je défini 'base_dir' de mock à /tmp/mock pour gagner en vitesse. Mais sous F25 /tmp est monté avec "nodev". En solution à l'arrache : "mount -o remount,dev /tmp".
Bref, je suis ravi.
Ravi également du décollage de Wayland, étape importante. Entre Xorg et Wayland, je prend Wayland car plus fiable.
C'est pas vraiment le problème.
Avec Ubuntu il faut que ça marche "out of the box", c'est attendu par ses utilisateurs.
Il y a eu les même problèmes avec Fedora ?
Admettons, mais le propos de Fedora n'est pas d'être rocksolid, mais de proposer les dernières technologies du logiciel libre qui feront l'avenir du logiciel libre (et aussi mettre à maturation des technologies pour RHEL qui n'ont pas encore trouvées leur place dans la "communauté" du logiciel libre). Ça ne veut pas dire que Fedora accepte n'importe quoi, mais il y a un compromis entre le risque de prendre les dernières technos et un système qui continue de rendre service à ses utilisateurs. Donc on tolère plus que ça "casse" avec Fedora. Ubuntu n'est pas sur ce compromis. Il y a des compromis pour Ubuntu, évidement, mais il n'y a pas ce compromis.
Le problème est que Pulseaudio a eu une mauvaise image notamment à cause d'Ubuntu. Quand je dis ça, je ne dis pas qu'Ubuntu a fait des conneries avec Pulseaudio, j'en sais rien et ça ne m'intéresse pas vraiment. S'il y avait des problèmes sur Fedora et Ubuntu, alors Ubuntu ne devait pas intégrer Pulseaudio, Ubuntu devrait attendre. Que ce soit un problème de Pulseaudio ou Alsa ne change pas ce constat.
Je suis un utilisateur de Fedora depuis FC1, je n'ai jamais eu de problème avec Pulseaudio, en tout cas suffisamment anecdotique pour que je n'en ai pas un souvenir précis.
"Ca fait 30 ans qu'on applique la politique de favoriser les patrons au détriments des salariés pour les inciter à embaucher. Car les salariés n'embauchent pas, que les patrons le font. Ca ne peut que marcher.".
Ça me faire rire. Si c'est le cas, pourquoi on est l'un des pays les moins favorables pour les patrons ?
Faudrait arrêter de dire qu'on l'a fait alors qu'on ne l'a pas fait.
Les autres pays, dont les socialistes des autres pays, ont compris qu'on n'a pas à demander à l'économie de faire du social, que c'est contreproductif. Faudrait qu'un jour les socialistes le comprennent. La sécurité n'est pas à donner par les entreprises, mais par l'état (via formation, capacité d'adaptation, etc).
On voit bien que la team "Rebelz" prise en étau entre les fous de Bachar et les fous d’Allah est en bien mauvaise posture et on imagine assez mal comment ils pourraient réussir à sauver leur petit cul…
Étonnement (ou pas), ils s'en tirent bien. Les Russes pensaient n'en faire qu'une bouchée, ça ne se présente pas du tout ainsi. En un mois d'intervention Russe, en gros rien n'a changé.
Le drame se poursuit et probablement pour longtemps. Les Russes qui ont peu d'armes de précision font des dégâts chez les civils, faudra pas longtemps pour qu'ils soient détestés par les Syriens (sauf pour les "places fortes" gouvernementale).
# Pataquès
Posté par Pseudo007 . En réponse au journal TousAntiCovid Carnets, sans TousAntiCovid. Évalué à 1.
Que ce soit libre, c'est mieux.
Mais que le principe puisse faire tout ce Pataquès me sidère.
J'en ai rien à foutre que quelqu'un sache si je suis vacciné ou pas. C'est d'autant plus débile que si tu vas à un rassemblement de plus de 1000 personnes, on sait que t'es vacciné.
Y a une paranoïa de taré actuellement.
[^] # Re: grub.cfg
Posté par Pseudo007 . En réponse à la dépêche Fedora 34 du nouveau : logo, versions de logiciels, documentation et un peu de Borsalinux. Évalué à 4.
La librairie libasound est toujours utilisée, et par pipewire aussi.
Il y a seulement la partie "traitement du signal" (mixage, filtrage, etc) de Alsa qui n'est plus utilisée car redondante (avec pulse, jack et pipewire).
[^] # Re: Fedora 34 l'outil de conquête du Monde d'IBM
Posté par Pseudo007 . En réponse à la dépêche Fedora 34 du nouveau : logo, versions de logiciels, documentation et un peu de Borsalinux. Évalué à 1.
Si avec ça on peut conquérir le monde, je m'y mets dès demain.
En passant, de combien a bondi l'action d'IBM après cette "puissante" déclaration ? J'imagine d'au moins 30 %. Non ?
[^] # Re: logo
Posté par Pseudo007 . En réponse à la dépêche Fedora 34 du nouveau : logo, versions de logiciels, documentation et un peu de Borsalinux. Évalué à 3.
J'ai installé F34 depuis le premier jour de la Beta. Aucun problème notable alors que je l'utilise tous les jours. En fait j'utilise Fedora quasi tous les jours depuis des années.
Je n'ai pas remarqué le changement de logo. J'ai remarqué un changement cosmétique donc anecdotique. En même temps, on le voit peu !!!
Juste pour dire que je ne comprends pas qu'il soit l'objet d'une polémique vive.
Ne voyez aucun critique du logo là !
# grub.cfg
Posté par Pseudo007 . En réponse à la dépêche Fedora 34 du nouveau : logo, versions de logiciels, documentation et un peu de Borsalinux. Évalué à 5. Dernière modification le 27 avril 2021 à 20:27.
Le changement lié à grub.cfg est un peu expliqué dans cette dépêche, mais j'y reviens car je me suis fait "avoir".
J'ai dû refaire mon grub.cfg, donc j'ai tapé "grub2-mkconfig > /boot/efi/EFI/fedora/grub.cfg".
Je reboote, tout marche comme prévu, aucun de problème.
Il faut noter que sur Fedora (et probablement bien d'autres), sauf changement majeur, on n'a pas à faire de grub2-mkconfig, grub.cfg ne change plus même quand on installe un noyau ou on change les paramètres de boot (cf /boot/loader).
Mais j'ai vu plus tard que le "vrai" grub.cfg n'est pas sur la partition /boot/efi, mais sur la partition /boot (ou / si vous n'avez pas de /boot comme moi).
Voila le contenu de /boot/efi/EFI/fedora/grub.cfg :
search --no-floppy --fs-uuid --set=dev 8213e1e1-66aa-4afa-aadc-3d6b0f8b5dec
set prefix=($dev)/boot/grub2
export $prefix
configfile $prefix/grub.cfg
Cela présente un avantage. Imaginons que /boot/efi soit sur /dev/sda? et /boot (ou /) sur /dev/sdb? . Si /dev/sda est mort, il vous suffit d'avoir un boot grub (par exemple sur une clé USB) et de faire un configfile (hd…)/grub2/grub.cfg. (ou /boot/grub2/grub.cfg).
Je trouve que c'est un bon changement car l'OS est moins dépendant de la partition de boot EFI.
En passant.
Pipewire, dont il y a vraiment peu de doc utilisateur voire pas du tout (c'est fort dommage), ne remplace pas Alsa, ou alors qu'une petite partie. Les drivers audios sont uniquement dans Alsa.
# Ah le complostime...
Posté par Pseudo007 . En réponse au journal Tous anticovid comme passe sanitaire ?. Évalué à -3.
TousAntiCovid est est open source.
Et franchement, à moins, et peut-être, d'être un opposant, l'État en a rien à foutre de nous individuellement.
Imaginons que je trompe ma femme et que TousAntiCovid permet de le savoir, l'État s'en torche le fion.
TousAntiCovid n'est pas obligatoire et ne le sera pas, il rendra les choses plus pratique seulement.
L'État n'a AUCUN intérêt à bloquer ou limité l'économie.
Puis les thèses complotistes sur TousAntiCovid par des personnes qui utilisent une CB, un téléphone, facebook, un IP connue d'un fournisseur d'accès, etc. LOL quoi.
[^] # Re: systemd fait tout, sauf la vaisselle
Posté par Pseudo007 . En réponse au journal Systemd à la maison. Évalué à 5.
Faut arrêter avec les "systemd fait tout".
Systemd ne fera pas traitement de texte, pas serveur web, pas gestionnaire de base de données, etc.
En chiffre.
Le src.rpm de systemd fait 10Mo. L'ensemble des src.rpm de f34 fait 58Go.
Donc systemd c'est 0,017 % d'une Fedora. Ce sont des chiffres pour donner un ordre de grandeur, rien de plus. Sur un installation desktop minimum (par exemple le profil "Fedora Workstation" sans rien de plus), ça doit faire maxi 0,5%. Si systemd faisait tout, on se passerait des 99,5 % qui constitue le "reste".
Le problème des services utilisateurs est qu'il doivent être gérés.
Cas plus intéressant, les démons utilisateurs qui ne doivent être là que lorsque la session est ouverte.
Avec systemd, on est sûr qu'à la fin de la session le service utilisateur est tué. On peut aussi être sûr qu'il va être relancé s'il plante. On est sûr qu'il est comptabilité dans les ressources (dont la mémoire), etc. S'il y a des dépendances, systemd le gère.
Il est donc complètement normal que systemd le fasse. Et ça sera plus fin. Avec SeLinux, il sera aussi vérifié que cette appli ne se connecte pas partout, etc.
Cet aspect utilisateur de systemd ne fait que commencer. On pourra à l'avenir, en étant utilisateur, télécharge des applis tiers, qui ne sont pas de confiance, et les faire tourner sans risque (plus besoin comme aujourd'hui de créer un compte séparé ou un container, etc). Quand on arrête l'appli, on est sûr qu'elle est arrêtée. Ce qui avant était loin d'être évident…
Quand on comprend le rôle de systemd, on comprend qu'il n'est pas là pour tout faire. Évidemment, certains diront que tel ou tel truc pouvait ne pas être dans systemd. Ya toujours des exceptions pour confirmer la règle.
# Je vais donner l'impression de troller mais ... BTRFS ?
Posté par Pseudo007 . En réponse au journal Sauvegarde le retour du retour. Évalué à 1.
En passant sur Fedora 33, je suis passé à btrfs, c'est le fs par défaut pour le profil "Workstation".
J'ai survolé les caractéristiques de btrfs et ça n’excitait pas mal. Les snapshots et les volumes logiques qui partagent un même volume physique (j'ai oublié les termes techniques).
Puis j'ai creusé un peu la doc de btrfs. J'ai vu 2 défauts (pour moi).
Désolé mais j'ai oublié un des défauts (je crois que c'est lié au raid où les perfs ne sont pas toujours au niveau attendu, mais c'est un peu accessoire ici).
Le gros défaut (pour moi hein) est que btrfs ne gère pas les "badblocks". Il m'est arrivé d'avoir des disques avec quelques secteurs défectueux et qui marchent encore durant des années. Évidemment, si les données sont précieuses, on peut bien casquer pour avoir des disques sans secteurs défectueux. Surtout que les disques sont peu chers (sauf si on stocke du lourd genre beaucoup de vidéos).
Bref, je suis retourné à ext4. Formatage et tout, un peu pénible de refaire ce qu'on vient faire.
Je ne dissuade pas d'utiliser btrfs qui est un bon fs avec des fonctionnalités très alléchantes. Surtout que les SDD, de plus en plus courants, gèrent eux-même les badblocks.
Je donne cette info car j'ai remarqué qu'elle était pas très connue et que j'étais très surpris de constater ce manque.
[^] # Re: Une grande inconnue
Posté par Pseudo007 . En réponse au journal Slackware 15 en approche ?. Évalué à 2.
Toutes ces spécificités à Linux (systemd, cgroup, etc) n'intéressent que ceux qui en ont besoin. Ce n'est pas parce que je fais un programme pour Linux que j'ai besoin d'utiliser ce qui est spécifique à Linux.
Mais si je veux faire un service (pas qu'un processus) qui par exemple a un quota pour la mémoire, je ne peux le faire qu'avec Linux et cgroupv2 (qui lui exige Systemd). Ou un firewall sur les services et pas que port/adresse, là encore il faut cgroupv2. L'autre dira qu'il s'en fout…
Si je veux faire un service qui demande un id user dynamique (des sortes de compte utilisateur créé à la volée), je peux le faire avec Linux (et je crois, mais pas sûr, que ça exige Systemd).
Personne ne fait du spécifique Linux sans raison.
Quand on regarde les gros programmes comme httpd, postgresql, etc, ils ont quasi tous du code spécifique pour Linux. Ils pourraient l'enlever, mais ça sera moins bien sur Linux. Et ils font la même chose pour FreeBSD, etc.
[^] # Re: Une grande inconnue
Posté par Pseudo007 . En réponse au journal Slackware 15 en approche ?. Évalué à 1.
Cela a toujours été l'intention de Systemd. Tous les anciens programmes doivent marcher avec Systemd, rien ne doit être cassé (sauf quelques fichiers init qui ne sont pas pris en charge mais il y a des solutions pour ça).
Je n'ai pas dit que tous les nouveaux marcheront avec l'ancien init.
Gnome si on veut tous ses fonctionnalités demande systemd. Idem pour udisks, etc.
[^] # Re: Une grande inconnue
Posté par Pseudo007 . En réponse au journal Slackware 15 en approche ?. Évalué à -10.
C'est quand même gonfler de dire que je trolle alors que c'est vous qui trollez.
Et là encore avec un "init parmi plein d'autres". Si c'était le cas, certains n'en auraient pas fait un gros caca. Si c'était le cas, on se demande pourquoi vous en parlez sans qu'on vous le demande.
Quand vous vous foutez de quelqu'un, faites le avec "finesse".
Vous vous en foutez, mais il y a 6 fois "systemd" dans votre post. C'est très cohérent. Hein?
Ah bon ?
Donc il fallait dire dès le début : "si vous voulez SystemD ou autre, vous pouvez".
Mais ce n'est pas votre choix. Vous avez dit "tout le monde s'en fout".
Donc la vous expliquez que Slack donne une possibilité dont tout le monde se fout ?
Vous êtes tordu.
Bravo, vous avez enfoncé une porte ouverte. J'espère que votre épaule ne vous fait pas trop mal pour ça.
J'avais écrit : "En général les auteurs de logiciel font des programmes pour des OS, voire le dénominateur commun des OS."
https://docs.slackware.com/slackware:localization
" Note that Slackware is not fully Unicode-prepared. Some applications (like the man pages) will not properly display Unicode text. For some languages (in particular the non-Latin ones) it is mandatory to enable Unicode support (see further down) or else the character glyphs will not be displayed (you will see nothing but small rectangles instead)."
Unicode n'est toujours pas par défaut.
Ceci dit, je m'en fous, j'utilise pas Slack.
Donc arrête d'en parler.
[^] # Re: Une grande inconnue
Posté par Pseudo007 . En réponse au journal Slackware 15 en approche ?. Évalué à 1.
Le truc à la mode ?
Il y en a qui ne veulent pas de systemd, très bien, ils font comme ils veulent. Mais ce type d'argument est stupide.
Là je ne peux pas dire que l'argument est stupide, mais il est douteux.
Peut-être disiez vous la même chose pour PAM, puis UTF8, PulseAudio, etc.
Toutes ces choses où finalement SlackWare vous a "forcé la main".
Qu'en sera-t-il pour Systemd ?
Personne ne force personne. Ce qui veut aussi dire que vous ne pouvez pas forcer les développeurs à ne pas passer à Systemd s'ils le souhaitent.
Il y a des conservateurs qui ne veulent pas suivre le "progrès" (<= guillemets), parfois ils ont raison, parfois tort.
Tout le monde s'en fout ?
Carrément.
J'suis comme Imarcini, j'ai commencé avec une Kheops, avec une Slack quoi. C'était en 95 (linux 1.2, sans module, ça ne nous rajeunit pas…), donc le vieux système init j'en ai bouffé durant des années puisqu'il n'y avait que ça. Puis est arrivé Systemd, un petit délai d'adaptation, et je ne regrette pas du tout le système init, pas du tout du tout. Je ne dis pas que c'était de la merde, mais que je n'ai aucune "nostalgie".
Et pour ceux qui n'ont pas prévu le système init (à l'ancienne), ce n'est donc pas sur Slack ?
Systemd est plus simple pour les développeurs. Il est maintenant plus répandu, donc peut-être qu'à terme certains développeurs upstreams ne feront plus de script init (entre autre car ils n'ont pas de distribution pour les tester). Si des "Slackeux" veulent faire un patch (upstream ou pour la Slack), c'est génial, ça ne me pose aucun soucis.
En général les auteurs de logiciel font des programmes pour des OS, voire le dénominateur commun des OS. Si les OS changent, ils s'adaptent. Ils sont forcément en retard. Je ne critique pas, je dis que ça ne peut être qu'ainsi pour la majorité des développeurs. Qu'ils soient en retard n'indique pas que les évolutions de l'OS sont mauvaises.
[^] # Re: Boot Loader Specification (blscfg de grub2)
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 est sortie !. Évalué à 4. Dernière modification le 01 novembre 2019 à 08:31.
Ah la résistance au changement…
Le menu.lst que tu édites à la main (donc que le système ne devrait pas gérer) est maintenant : /etc/grub.d/40_custom
Le gros problème de menu.lst, est qu'il est édité par l'utilisateur et le système. 40_custom est géré que par l'utilisateur.
Est-ce que le menu.lst gérait les échecs de boot pour proposer un mode "sans échec" ? Je ne crois pas.
Est-ce qu'il gère le boot par défaut "automatiquement" ? Je ne crois pas.
Je donne un exemple concret d'avantage pour moi de Boot Loader Specification.
J'ai plusieurs disques durs sur mon système. Un disque est le boot "habituel", un autre un backup (typiquement hebdomadaire avec rsync). Si le boot habituel ne marche pas, je boote sur le backup.
Avant à chaque backup je devais éditer grub.cfg (c'est fait par script avec des sed). Maintenant je n'ai rien à faire. Évidemment que je dois toujours copier /boot (pas /boot/efi), mais c'est tout. Et il ne faut pas oublier que /boot n'a pas forcément à avoir sa propre partition, ça peut être la partition racine (ce qui est le cas chez moi).
[^] # Re: Boot Loader Specification (blscfg de grub2)
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 est sortie !. Évalué à 1.
Désolé pour la présention, mais "code block" marche pas.
# Boot Loader Specification (blscfg de grub2)
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 est sortie !. Évalué à 4. Dernière modification le 31 octobre 2019 à 13:43.
(c'est uniquement pour vous mettre l'eau à la bouche)
Ce n'est pas une nouveauté f31, mais f30 ou f29, que j'ai raté car je suis passé de f29 à f31 (oui c'est mal).
Quand on ajoute un noyau à son GNU/Linux chéri, vous savez comment ça se passe, il faut changer grub.cfg. C'est fait, sous Fedora, par une usine à gaz nommée grubby. Si c'est automatisé et que les programmes font bien leur job, ce n'est pas vraiment souci. Mais si vous ajoutez à la main un noyau, etc.
Donc Fedora utilise maintenant Boot Loader Specification :
https://systemd.io/BOOT_LOADER_SPECIFICATION
Comment ça marche concrètement ?
Si j'ajoute un noyau (avec son initrd) à ma machine, il me suffit de déposer un fichier qui décrit ce noyau dans /boot/loader/entries/ . Le nom du fichier doit être machineId_CeQueVousVoulez.conf. machineId est à récupérer de /etc/machine-id.
Exemple de fichier :
Si vous supprimez le noyau, il vous suffit de supprimer le ficher pour qu'il n'apparaisse plus dans grub lors du boot.
Un lecteur attentif aura remarqué qu'on n'a pas tout pour pouvoir booter, notamment il manque la partition root. Quand on ajoute un noyau, on ne change pas de root, donc l'information n'a pas à être dans ce fichier. Néanmoins c'est récupéré dans la variable $kernelopts qui est définit dans grub.cfg.
Dans mon grub.cfg j'ai :
set default_kernelopts="root=UUID=033fead8-f5bf-4433-a108-74c7359b96c1 ro rd.md.uuid=8ac3b7b8-1bc9-7973-15a8-1361718c00ae"
Comment grub prend en compte les fichiers dans /boot/loader/entries ?
Il le fait lors du boot et va créer "à la volée" une entrée grub classique (qu'on pourra éditer avec grub au boot si nécessaire) genre :
C'est demandé dans le fichier grub.cfg par :
Et voilà !
C'est une petite chose mais je suis ravi de le voir car avant c'est vraiment "hugly".
# Fedora Toolbox
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 est sortie !. Évalué à 10.
Fedora Toolbox est un petit utilitaire bien pratique.
Il crée une sorte de chroot mais on conserve son home. Il ne demande pas d'être root même pour y installer des paquets. C'est à moitié vrai, on fait "sudo ou su" sans avoir à rentrer de mot de passe. Tout est dans $HOME ($HOME/.local/share/containers). Depuis ce chroot on peut aussi lancer des applis graphiques.
C'est très simple d'emploi. Idéal pour un environnement de développement où on peut être amené à installer plein de paquets. Ainsi ça évite de "saloper" son OS principal. Si on fait tout son boulot dans $HOME comme il se doit, il n'y a rien à sauvegarder, c'est le $HOME principal (on peut détruit le container, rien est perdu).
https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
Très cool.
PS: je ne sais pas ce qu'il y a sous le capot (je le devine un peu néanmoins).
# Fedora 31 est sorti
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 1.
Annonce : https://fedoramagazine.org/announcing-fedora-31/
Release notes : https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/
À un paquet près, c'est un snapshot de la branche "development" (NB: qui n'est pas rawhide).
# retour rapide
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 1.
J'ai installé aujourd'hui.
Anaconda ne m'a pas rassuré, j'ai dû faire plusieurs essais (il se plaignait des partitions qui devraient être GPT alors qu'elles le sont déjà et je ne sais quoi d'autre avec UEFI). Finalement, et je ne sais comment, mais cela a marché après plusieurs tentatives. J'ai un système avec 6 disques, mais ce n'est pas une excuse, cette partie de l'installeur doit être bétonnée. Avant d'arriver sur la page principal de l'installeur, on passe sur un écran où on choisi la langue, puis un écran pour le réseau. Pour ce deuxième écran le clavier n'est pas configuré. Je ne comprenais pas pourquoi je n'arrivais pas à me connecter à mon wifi, le mot de passe n'était pas le bon (NB: pas d'option d'affichage du mot de passe pour savoir ce qu'on tape et pas d'autre champ pour faire un essai). Vu qu'on peut configurer le réseau plus loin, avec le clavier configuré (et aussi voir le mot de passe), ce n'est pas très gênant.
Tout le reste va presque pour le mieux dans le meilleur des mondes sauf peut-être un réglage de la vm ou cache disque qui rend le système quasi inutilisable lorsque je fais des grosses copies de fichiers et que le cache est "sous pression" (je débite entre 200 et 300 Mo/s sur mon maintenant vieux i7). C'est beaucoup mieux lorsqu'on vire le swap (j'ai assez de mémoire pour le faire). Petit désagrément pour les consoles textes, elles ne prennent pas tout l'écran. Toujours le même problème de l'interface Firefox en anglais.
Tout le reste a bien marché "out of the box". Le DAC reconnu et utilisé par défaut, casque Bluetooth nickel, pas de soucis avec rpmfusion, etc.
Ce n'est plus la même excitation qu'il y a quelques années. Le système évolue peu, il se peaufine. Je ne m'en plains pas.
[^] # Re: Fin du 32 bits?
Posté par Pseudo007 . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 2.
Vu que ça ne marche plus sur du hardware 32 bits, ce n'est plus une distrib 32 bits. Les applis 32 bits marchent toujours.
# Modularité
Posté par Pseudo007 . En réponse à la dépêche Fedora 28 est sortie dans les temps !. Évalué à 2.
Mauvaise copié d'écran pour illustrer la "modularité".
La modularité s'active via les paquets fedora-repos-modular et, pour les plus courageux, fedora-repos-rawhide-modular.
S'utilise avec dnf (pour fedora-repos-modular) :
# dnf module list
Fedora Modular 28 - x86_64
Name Stream Version Profiles
nodejs 6 20180308155546 default, development, …
reviewboard 2.5 [d] 20180206144254 default, server
# Petit retour d'expérience
Posté par Pseudo007 . En réponse à la dépêche Fedora 25 est disponible !. Évalué à 10.
J'ai F25 depuis 1 mois (évidemment via un passage par la version beta).
Utilisation du bureau Gnome/Wayland.
Wayland fait perdre quelques fonctionnalités, mais rien d'important. En fonction des besoins, ça peut être irritant. Donc fournir X11 est nécessaire encore et peut-être pour assez longtemps.
Wayland chez moi est "rocksolid". Avec Xorg j'avais parfois des plantages, aussi des soucis avec gnome-shell quand utilisation de libva (vaapi). L'affichage en 3D de http://flightradar24.com/ dans Firefox faisait parfois planter Xorg. Avec F25 je n'ai eu absolument aucun problème de fiabilité avec Wayland ! Rien, nada. Chapeau bas !
Je suis convaincu que la grande majorité des utilisateurs de Gnome seront sous Wayland avec F25.
Avant j'avais F23, mais il restait trop de limitation pour utiliser en permanence Wayland (à l'époque déjà rocksolid).
Le problème le plus irritant que j'ai avec Wayland est qu'un "su -l" (ou sudo) ne configure pas l'environnement pour utiliser Wayland (il faut utiliser xhost et définir $DISPLAY à la main). C'est bien un bug de l'intégration de Wayland. Je précise qu'il reste des défauts, mais ils sont anecdotiques.
Pour le reste, ben j'ai rien à dire, tout marche comme prévu, désolé.
Dans les très nombreuses versions de Fedora que j'ai utilisé (je suis sous Fedora depuis le début de Fedora), c'est celle qui a la meilleure qualité. Après de mémoire ça devait être la version 13 ou 15.
Le seul moment où j'ai fait un peu de recherche car j'avais un problème était avec mock. Je défini 'base_dir' de mock à /tmp/mock pour gagner en vitesse. Mais sous F25 /tmp est monté avec "nodev". En solution à l'arrache : "mount -o remount,dev /tmp".
Bref, je suis ravi.
Ravi également du décollage de Wayland, étape importante. Entre Xorg et Wayland, je prend Wayland car plus fiable.
[^] # Re: Ubuntu a bon dos
Posté par Pseudo007 . En réponse au journal Campagne de financement pour PulseAudio. Évalué à 7.
Ubuntu a bon dos ?
C'est pas vraiment le problème.
Avec Ubuntu il faut que ça marche "out of the box", c'est attendu par ses utilisateurs.
Il y a eu les même problèmes avec Fedora ?
Admettons, mais le propos de Fedora n'est pas d'être rocksolid, mais de proposer les dernières technologies du logiciel libre qui feront l'avenir du logiciel libre (et aussi mettre à maturation des technologies pour RHEL qui n'ont pas encore trouvées leur place dans la "communauté" du logiciel libre). Ça ne veut pas dire que Fedora accepte n'importe quoi, mais il y a un compromis entre le risque de prendre les dernières technos et un système qui continue de rendre service à ses utilisateurs. Donc on tolère plus que ça "casse" avec Fedora. Ubuntu n'est pas sur ce compromis. Il y a des compromis pour Ubuntu, évidement, mais il n'y a pas ce compromis.
Le problème est que Pulseaudio a eu une mauvaise image notamment à cause d'Ubuntu. Quand je dis ça, je ne dis pas qu'Ubuntu a fait des conneries avec Pulseaudio, j'en sais rien et ça ne m'intéresse pas vraiment. S'il y avait des problèmes sur Fedora et Ubuntu, alors Ubuntu ne devait pas intégrer Pulseaudio, Ubuntu devrait attendre. Que ce soit un problème de Pulseaudio ou Alsa ne change pas ce constat.
Je suis un utilisateur de Fedora depuis FC1, je n'ai jamais eu de problème avec Pulseaudio, en tout cas suffisamment anecdotique pour que je n'en ai pas un souvenir précis.
[^] # Re: Ah notre gouvernement ...
Posté par Pseudo007 . En réponse au journal Projet de loi français El Khomri. Évalué à -1.
Ça me faire rire. Si c'est le cas, pourquoi on est l'un des pays les moins favorables pour les patrons ?
Faudrait arrêter de dire qu'on l'a fait alors qu'on ne l'a pas fait.
Les autres pays, dont les socialistes des autres pays, ont compris qu'on n'a pas à demander à l'économie de faire du social, que c'est contreproductif. Faudrait qu'un jour les socialistes le comprennent. La sécurité n'est pas à donner par les entreprises, mais par l'état (via formation, capacité d'adaptation, etc).
Quel pays fait ça et où ça marche ?
Aucun.
# team "Rebelz"
Posté par Pseudo007 . En réponse au journal C’est toujours la guerre en Syrie. Évalué à 0.
Étonnement (ou pas), ils s'en tirent bien. Les Russes pensaient n'en faire qu'une bouchée, ça ne se présente pas du tout ainsi. En un mois d'intervention Russe, en gros rien n'a changé.
Le drame se poursuit et probablement pour longtemps. Les Russes qui ont peu d'armes de précision font des dégâts chez les civils, faudra pas longtemps pour qu'ils soient détestés par les Syriens (sauf pour les "places fortes" gouvernementale).
C'est moche.
[^] # Re: Pourquoi XFS pour le /home ?
Posté par Pseudo007 . En réponse à la dépêche Nouvelle openSUSE Leap : 42.1. Évalué à 0.
Ou ils sont pas plus con que Red Hat et savent qu'actuellement c'est la meilleure solution. Faire différent pour faire différent, quel est l'intérêt ?