Pour le droit moral, qui est incessible, ça se passe comment?
Alors en informatique l'auteur du logiciel est celui qui en a écrit les specs, pas le codeur. De plus si tu travailles sous contrat (y compris consulting, CD CDD), même sur des specs que tu as écrites toi même, l'auteur est ton employeur. Pour finir le droit moral en informatique c'est peau de chagrin, pas de droit au repentir ou au retrait, pas de droit sur les adaptations etc. Bref il reste le droit au nom (et une fois de plus dans le cadre d'un contrat ce sera le nom de l'employeur)
L'exemple que tu prends est loin d'être aussi anodin que tu le penses,
Aujourd'hui quand on prend une distribution Linux, on se retrouve souvent avec Google comme moteur de recherche par défaut, et assez souvent comme page de démarrage.
Est-ce une bonne chose ? C'est ce dont la plupart des utilisateurs ont l'habitude. Donc c'est ce qui dérange le moins les utilisateurs statistiquement. Cependant
- Duck Duck Go est bien meilleur au niveau du respect de la vie privée
- Yahoo avec son système de catalogue est plus adapté pour les grands débutants
- Un meta-moteur custom peut surprendre l'utilisateur, mais permettre des résultats plus pertinents
Donc que fait-on ? On laisse Google, avec la possibilité de changer ?(de plus en plus planquée la possibilité, les barres d'outils étant en voie de disparition dans les navigateurs). On met Duck Duck GO pour le respect de la vie privée avec un bouton bien visible pour passer en mode Google, mais sans aucune explication ? Ou alors on met un petit laius au premier lancement du logiciel en priant pour que la personne le lise et en fasse pas next, next, next.
Même sur le libre on peut faire des choix d'office à la place de l'utilisateur, et ça permettra à l'utilisateur de rentrer plus vite dans le produit. Mais est-ce une bonne idée ?
Les gens veulent Google en moteur de recherche et en page de démarrage. Donc soit on le leur donne sans réfléchir (auquel cas l’intérêt du libre est rigoureusement 0), soit on essaye de les inciter à perdre un automatisme qui ne se justifie pas forcément.
Cette remise en cause des automatismes est nécessaire, même si oui elle casse les pieds au client. Quand on oblige les mots de passe à avoir une certaine taille, quand on les forces à changer de façon significative d'une fois sur l'autre, quand on leur enlève des raccourcis dangereux ou qu'on leur bloque des comportements à risque. Bien sur on casse les pieds à l'utilisateur, et au passage on se casse les pieds à soi aussi. Il ne s'agit pas seulement de chercher à résoudre son problème propre plutôt que le problème de l'utilisateur, mais bel et bien de chercher à créer un environnement fiable et pérenne.
Forcément ça fait grincer les dents des utilisateurs au début, et bien entendu il faut avoir un produit de qualité et qui rend de vrais services pour que le dit utilisateur continue à utiliser notre service/logiciel. Mais généralement ça vaut le coup sur le moyen-long terme.
La communauté/les dev logiciel libre, sous prétexte que c'est mieux pour l'utilisateur (et ce n'est pas entièrement faux)
Ah mais si tu veux un ordinateur préconfiguré, qui vient avec son abonnement ADSL et son email pré-installé et nominatif, et tous les paramètres choisis d'avance - c'est pas un problème, c'est très facile à faire. Prend par exemple windows 98, il venait avec son navigateur internet, le moteur de recherche plugué sur MSN, il y avait un joli logo "se connecter à internet" qui te permettait d'avoir une connexion MSN assez rapidement pour peu que l'on ait eu un modem et une carte bleue. Bien sur le navigateur c'était IE 5 avec les ActiveX grands ouverts.
Et le libre a ramé, mais alors ramé de chez ramé pour freiner la tendance puis l'inverser. Bonjour la bataille pour que phenix devenu firebird devenu firefox s'impose (Ben oui ton truc il marche pas sur le serveur de ma banque alors je suis retourné sous IE), bonjour la bataille pour limiter les ActiveX, le tout avec l'ART devenu ARCEP qui tapait sur les offres Ordi+abonnement internet+communications pour une mensualité défini sur une durée de 36 mois.
Pourtant c'était vachement plus simple pour le client, il rentrait chez lui, il branchait l'ordinateur, le modem dans la prise et hop il recevait directement des emails à son nom sur sa machine. 0% installation, 100% prison.
Et oui il a fallu expliquer aux gens, leur expliquer pourquoi le truc qui marchait moins bien et qui était plus compliqué était mieux pour eux. Dieu merci à l'époque de Windows 98 les gens étaient suffisamment en colère contre Microsoft pour nous écouter. Apple était pas encore complètement reparti et les gens cherchaient des alternatives.
Maintenant c'est clair que la machine pré-configurée ras la gueule, avec fichage du client et détermination des services par un tiers c'est le contraire exact du libre. Et la seule parade, vu que l'on va avoir du mal à chopper les accords commerciaux et les designers des logiciels proprio, c'est de pousser les gens à
- Premièrement déterminer précisément ce dont ils ont besoin
- Deuxièmement apprendre à se documenter par eux même
- Troisièmement refuser les solutions toutes faites si elles ne conviennent pas au besoin.
J'ignore a quel moment on est passé de lire le manuel -> les options ça évite de lire le manuel -> Imagine qu'on doive choisir la taille et la couleur de tous les titres des fenêtres avant de lancer gnome; mais vous m'impressionnez les mecs.
Pourtant je suis pas mauvais en mauvaise foi et en sophismes déplacés, mais là chapeau bas.
Tout d'abord devoir lire un manuel pour tirer parti pleinement du LL ne veut en aucun cas dire devoir apprendre par coeur l'ensemble des pages du manuel concerné avant de pouvoir lancer le programme. La grosse majorité des logiciels libres ont un comportement par défaut relativement acceptable. La nécessité de lire le manuel se trouve surtout quand on a besoin de sortir de ce comportement par défaut. Même Apache-Tomcat, qui est à mon sens la pire des horreurs jamais créé en terme de fichier de config, permet de lancer des servlets en quelques minutes après l'install (sur 127.0.0.1:8080 d'accord). Ca fait quand même un moment que les configs imbitables à coup de m4 et de make, merci sendmail, ont disparues.
Maintenant les configs par défaut, les logiciels proprios en ont aussi. Et vu que les logiciels proprios forcent l'utilisateur a utiliser des solutions prédéfinies (noyeau fixé, pilotes fixés, interfaces fixés etc.) et qu'ils ont des équipes de dingues au niveau de l'UI, les solutions par défaut des logiciels propriétaires seront toujours meilleure que les solutions par défaut des LL.
Peut importe que l'on doivent se palucher le fichier de config à la main, ou que l'on ait une belle interface graphique avec des gors boutons, à un moment ou à un autre il va falloir apprendre ce que ca veut dire activer le snmp v3. Et ça, ça passe par lire le manuel. Même un utilisateur lambda il doit savoir un minimum de chose, par exemple à l'installation d'office, si il choisit le mode de configuration manuel on va lui demander si il veut activer la prise en charge de la police universelle et si il veut sauvegarder au format OpenXML ou OpenDocument.
Et là soit il se renseigne, soit il y a des chances non négligeables que ses fichiers ne soient pas lisibles par ses petits camarades.
Si il prend l'installation par défaut, son Word ne s’intégrera pas forcément comme il faut avec la dataroom, et son format de sauvegarde ne sera pas forcément compatible avec celui des Office plus ancien.
Bref les configs par défaut ça a des limites, et ces limites sont beaucoup plus strictes si on est sur du proprio que sur du LL. C'est à mon sens à aujourd'hui le seul avantage tangible du LL. Pour tirer parti de cet avantage il faut lire le manuel et mettre les mains dans le cambouis au moins un peu. Si on est pas prêt à faire ça, le logiciel proprio est meilleur.
Justement, tes clients n'ont probablement pas lu le man
Il ne sont pas utilisateurs de Postfix, ils sont utilisateur du service qui va avec. C'est à l'utilisateur du serveur et pas du service de lire le manuel. Si il y a un problème au niveau 2 (donc au niveau du service) c'est à moi de le résoudre, et donc à moi de lire la doc.
Les utilisateurs eux reçoivent une doc sur comment configurer leur client mail avec mes serveurs, et la plupart y arrivent tout seul comme dans grands.
Ceci étant mon point reste valable, à savoir que le fait que j'utilise un logiciel libre m'apporte quelque chose, mais qu'il n'apporte strictement rien à mes clients. C'est toujours celui qui lit la doc qui peut tirer parti du LL.
Déjà, tu as perdu. De nous jours, un logiciel où il faut lire un manuel --> Poubelle, et on prend un logiciel intuitif, même si on perd de la liberté (laquelle?), on gagne du temps.
Non on perd du temps, au final mon postfix qui fait exactement ce que je demande, exactement comme je le veux avec les logs au format que je souhaite et les authentifications qui peuvent gérer ses deux bouses ultimes niveau TLS/SSL que sont Mail.app et Outlook m’économisent des heures de maintenance tous les mois.
Alors c'est vrai que j'aurais pu prendre un truc tout packagé et dire à mes clients "Ah oui avec Outlook 2003 ça marche pas" et "Mail.app interprète les déconnexion comme une erreur de mot de passe, fermez tout et retapez vos mot de passe encore une fois". Mais je préfère la solution actuelle. Je pense que mes clients aussi.
RTFM est perçu comme une insulte personnelle
Ca l'est.
Non l'insulte c'est de pourrir un forum avec des questions triviales qui prouvent que l'on a même pas pris trente secondes à chercher la réponse par soi-même. RTFM est juste la réponse à cette insulte.
et la plupart des questions des dits forums ont été posées tellement de fois qu'il suffit généralement de 8 seconde de recherche sur internet pour avoir la réponse.
Ca veut alors dire que le logiciel est mal conçu.
Non ça veut juste dire que la personne qui a conçu le logiciel te laisse toutes les possibilités pour sa mise en place. Mais plus tu as de choix dans ta config, plus tu as de paramètres à valider avant de pouvoir passer à un système fonctionnel.
Bref les gens ne veulent pas lire le manuel, veulent que ça marche "tout seul"
Et ils ont bien raison : la machine est au service de l'homme, pas l'inverse.
Neuf fois sur dix, quand une application marche "tout seul", c'est l'homme qui se retrouve au service de la machine. Personnellement une personne qui fait ce qu'elle veut, comme elle veut au moment ou elle veut j'appelle pas ça un domestique. Seulement la première étape quand on veut avoir quelque chose à son service c'est de lui donner des directives. Si on saute cette étape on a un truc qui fait peut être des choses intéressantes, mais qui n'est pas vraiment à notre service.
A partir de là pourquoi se casseraient-ils les pieds à enlever l'O.S fourni avec leur ordinateur.
Parce qu'il serait mieux?
En quoi ? Si on prend le fonctionnement de base sans y toucher, sans chercher à mettre une seule seconde les mains dans le cambouis comment le logiciel libre pourrait-il battre les hordes de designers d'interface et de graphistes de MS ou de Apple. Au mieux on aura des comportement différents qui plairont plus à une partie de la population que les comportements par défaut de Mac ou de Windows, au pire (et c'est malheureusement ce vers quoi le desktop semble glisser) on aura une tentative de copie carbone d'une interface ou l'autre.
Dans ce que je lis, tu as l'idée que le libre est le but.
Pas du tout non, ce que je dis c'est que le libre (en tant qu'outil) n'apporte rien à une personne qui ne veut pas mettre un minimum les mains dans le cambouis, et qu'à partir de là cette personne ne trouvera aucun intérêt à passer au libre. Bref, une personne qui se moque de la technique (en fait qui est techniquophobe, dans le sens ou elle vomit vert fluo quand on lui présente le manuel de l'utilisateur) n'a aucun intérêt à être sous Linux ou sous BSD. Elle sera bien mieux sous Mac ou sous Windows le jour ou elle aura un besoin spécifique. Là elle paye, elle branche/installe et ça marche. Pas besoin de se demander si le matériel est bien supporté ou si le package 64 bits est stable.
_Il y a manuel et manuel. Les pages mans sont des manuels de référence complètement inutilisable quand tu débutes. _
Je vais avoir du mal à pas faire passer ça pour un gros troll, mais si sous certaines distribs Linux ce que tu dis est vrai, sous FreeBSD tu peux parfaitement partir de 0 avec juste le docbook dans une main et les man pages dans l'autre. Et sous OpenBSD ils poussaient même le vice jusqu'à te renvoyer dès le début du manuel vers Understanding IP addresses http://holdenweb.com/static/docs/3comip.pdf (à lire absolument).
Bien sur à un moment ou à un autre il faudra passer sur une doc un peu plus conséquente, mais on peut aller vraiment loin juste avec la doc de base sous BSD.
Le plus gros défaut des logiciels libres c'est qu'on dispose de l'ensemble des outils pour en faire ce que l'on veut.
Ça implique un certain nombre de choses :
a) Déjà il faut savoir ce qu'on veut. Là tu as perdu 50 à 60% du marché.
b) Ensuite il y a le problème de disposer des outils. Généralement ça implique de passer un peu de temps pour s'approprier ces outils, ce qui induit généralement le fait de devoir LIRE LE MANUEL (taaaa dan <---- accord musical sinistre). Même sur les forums de ces excentriques de libriste (moins de 3% de la population totale) RTFM est perçu comme une insulte personnelle, et la plupart des questions des dits forums ont été posées tellement de fois qu'il suffit généralement de 8 seconde de recherche sur internet pour avoir la réponse. Si j'en crois les statistiques, on doit déjà s'être amputé d'un bon 98,5% du marché.(Et la je suis large, ça voudrait dire que la moitié des libristes lisent les man pages et les info pages des logiciels qu'il utilisent - non suivre les howto en mode copier-coller ne compte pas)
c) Finalement il y a le problème de faire. Ça implique du temps (et même parfois un budget dédié dans le cadre professionnel). C'est à dire des gens qui vont prendre de leur temps pour résoudre un problème qui n'est pas pris en charge de base par leur installation pour obtenir un résultat qui colle exactement à la virgule près à leur besoin. Ça va d'écrire un script d'init différent de celui fourni avec le paquet à coder une application complète, respectueuse des standards et fiable.
Quel est le pourcentage de libristes qui arrive jusqu'au c) ? Qui peut faire un ps x depuis l'utilisateur root et expliquer ligne à ligne à quoi correspond ce qu'il voit, à quoi ça sert, et comment le configurer ?
En bref quel est le pourcentage de "libristes" qui auraient exactement la même utilisation de leur machine personnelle si ils étaient sous Windows ou sous Mac OS X ? Pour les machines desktop ça doit être la grosse majorité, je dirais au pif un bon 70-80% (mesure pifométrique basé sur le fait que je suis un professionnel sur le sujet attendu que j'ai organisé trois install party et que j'ai filé un coup de main à un LUG une fois pour leur serveur mail.) Sur les serveurs ça doit pas être bien brillant non plus.
Bref les gens ne veulent pas lire le manuel, veulent que ça marche "tout seul" (même si du coup ils ne peuvent pas choisir la direction de cette marche) et ne veulent pas passer du temps à refaire mieux un truc qui marche presque assez bien pour eux. Donc le libre n'a strictement rien à leur apporter. A partir de là pourquoi se casseraient-ils les pieds à enlever l'O.S fourni avec leur ordinateur.
Tout d'abord, sur le tarif "entreprise" vs tarif particulier :
Clairement le tarif jaune, pour les consommations élevées est plus intéressant que le tarif bleu, mais pour un particulier ça se discute vraiment. Un tarif bleu arrive chez toi, dans un joli tableau électrique derrière un beau compteur le tout ayant été validé au moins une fois (des fois il y a longtemps, d'accord) par un organisme dit "le consuel".
Le tarif jaune arrive dans un local réservé de ton fournisseur, et tout le reste du raccord c'est ton problème. C'est donc à toi de tirer les cables, d'équilibrer les phases (j'y reviens), de séparer les consommations et de payer la facture. Tu es également légalement responsable de ta partie de l'installation, ce qui implique une assurance et une maintenance de l'existant.
Bref tu te poses en fournisseur de service, et sur l'électricité il y a pas mal de responsabilité qui viennent avec.
De plus les tarifs jaunes coûtent souvent beaucoup plus cher en terme d'abonnement, et une partie des frais nécessaire au passage d'un tarif à l'autre sont imputables au client. Par exemple si il faut remplacer deux ou trois cables existant par un seul gros cable pour le tarif jaune, ça peut faire mal.
Grosso-modo quand on installe un tarif jaune, il faut :
a) dédier un local d'alimentation à la répartition de l'électricité. Sauf cas particulier ce local doit être distinct du point d'arrivé de ton fournisseur. Dans ce local il faut mettre :
Le disjoncteur de puissance général
Pour les systèmes à fort changement (genre des apparts ou tout le monde rentre chez lui à la même heure, et allume lumière/télé/four/chauffage) un système d'équilibrage des phases
Un tableau de départ pour chaque appart
Équilibrer les phases ça veut dire s'arranger pour que le disjoncteur général ne claque pas quand on arrive à un tiers de la puissance. En effet le tarif jaune va arriver en triphasé, et à moins que tu ne passes dans tous les apparts pour vérifier tous les appareils électriques, il va falloir garder ce triphasé. Ca implique tout d'abord de générer un neutre, puis de se lancer dans une installation électrique complexe et couteuse pour que madame Michu qui déciderait de lancer la machine à laver, le séche linge et le chauffage en même temps
- ne disjoncte pas si elle est dans sa tranche de puissance
- ne fasse pas disjoncter le général si madame michmoch et madame michdule ont eu la même idée
- ne parasite pas madame michtruc qui veut juste regarder la télé.
En d'autres termes s'arranger pour que tous les habitants de l'immeuble reçoivent un courant sinusoïdal propre avec 3 phases capable de fournir la puissance demandée à chaque instant. Et l'air de rien c'est pas si évident que çà.
b) Le câblage devenant ta responsabilité légale, il va falloir t'assurer qu'il convient bien à la nouvelle installation. Généralement ca implique un électricien compétant, un passage du consuel, plusieurs coupures voire la mise en place d'une électricité de chantier avec dérivation et tout le toutim.
c) Il va également falloir que tu t'occupes de mettre en place les boîtiers de consommation, qui doivent obligatoirement être aux normes francaise d'une part, et accessibles à tout moment par l'usager final d'autre part.
Voilà pour le coté chantier à proprement parlé.
Ensuite il faut gérer les consommations, les facturations, les paiements, les demandes d'augmentation de puissance d'untel ou unetel, faire le relevés quand il y a changement d'utilisateur final etc. Amusant
Et enfin il faut payer les factures tarif jaune. Parce que le tarif jaune il peut être coupé beaucoup plus facilement que le bleu (même si dans la pratique les fournisseurs sont coulants pour les grosses factures qui ne leur demande pas autant de boulot que les particuliers). Ceci dit si un de tes habitants se retrouve dans une sale situation (genre monsieur est partie avec une danseuse, laissant madame et ses deux enfants derrière lui) ça peut vite poser un problème, surtout si le chauffage est électrique. Monsieur le juge ou les services sociaux t'interdiront de couper l'abonnement, et avec ton tarif jaune tu vas être bien mari pour le réduire en amont et ainsi diminuer tes coûts. Si dans l'immeuble il y a 6 occupants dont toi, tu vas te retrouver à avoir le choix entre payer un tiers de la facture tout seul de ta poche, ou priver l'ensemble de l'immeuble d'électricité avec les conséquences légales que ça peut avoir.
Bref pour 150€ par an et par abonnement et 0,036€ ça va être dur de gérer tout çà...
Gnome 3 avec Gnome-shell est en train de se prendre de plein fouet la loi du 90/90 à savoir :
90% des utilisateur veulent absolument faire au moins une chose dont 90% des utilisateurs n'ont strictement rien à foutre. De madame Michu qui veut regarder ses emissions sur la redif TF3 à Jean-Kevin qui a vraiment envie d'avoir deux cartes wifi distinctes sur sa machine, toutes les deux actives en même temps.
Quand au dockappsdockletsdesklets extensions, je ne veux pas être méchant mais si on oublie les inénarrables bidule de météo qui clignotent, la plupart des "extensions" de Gnome Shell consistent pour l'instant soit en des réimplémentation des anciennes interfaces, soit carrément des extensions qui suppriment ou masquent des fonctionnalités de Gnome Shell.
Bref on utilise une surcouche logicielle pour enlever une autre surcouche logicielle qui rajoute des fonctionnalités/comportement qui sont loin de faire l’unanimité. Alors bon on sait depuis Gstreamer que Gnome n'a pas peur d'en tenir une bonne surcouche, mais là quand même si on prend toutes les extensions et qu'on les installe, on se retrouve avec un Gnome-Shell maquillé en Gnome2, une applet météo et un truc qui s’appelle zeitgeist, qui ressemble à Beagle, mais pas trop (les paris sont ouvert sur la viabilité du truc, il a déjà changé de nom deux fois), le tout pour à peine la consommation CPU/RAM/Video d'un cluster de station IRIX en pleine analyse des collisions du LHC.
Ceci étant, oui les gens passeront à Gnome 3 + Gnome Shell au bout d'un moment. Déjà parce que je ne pense pas qu'un fork de Gnome2 arrive à suivre le rythme de façon soutenue, deuxièmement parce que les Linuxiens du desktop ils aiment bien les trucs trop joli à regarder même si ça ne leur apporte rien et enfin parce que faire des packages GTK2+Gnome2+interfaces dbus/ systemd/HAL qui collent avec une distrib donnée c'est déjà pas évident (CF Slackware), mais alors faire la même chose sur une distrib qui s'appuie fortement sur Gnome 3 sans rien casser ca doit être franchement coton.
Vu la façon dont les outils systèmes gnome s'enfoncent de plus en plus profondément dans la config de base du système, il va bientôt falloir prendre des distribs spécialisées KDE (ou en tout cas avec aussi peu de GTK/Gnome que possible) pour avoir une chance de pouvoir compiler/installer une version Gnome non "canon". Bref quand on aura le choix entre Gnome-Shell ou LFS, le choix sera vite fait.
Maintenant, hypothèse qui n'a pas été évoquée, mais qui reste réelle : Et si gnome-shell finissait par claquer entrainnant Gnome3 dans sa chute.
C'est peu probable quand même, vu Red Hat qui pousse derrière (Mais bon Red Hat, quand il s'agit de balancer à la poubelle la techno phare de la release précédente ça ne leur fait pas vraiment peur.) Néanmoins entre KDE qui ne fait pas que des heureux, Gnome qui dégoutte même ses fans les plus fidèles, XFCE et LXDE qui sont presque mais pas suffisant, il y a aujourd'hui pour la première fois une vraie place à prendre pour un outsider. Et dans le monde du libre, quand il y a une place à prendre...
Pour la webcam je ne crois pas que ce soit facilement possible, pour les deux autres RDP fournit les moyens d'exporter les disques locaux sur la machine distante et de jouer le son de la machine distante soit en local, soit en distant.
Ceci étant c'est quand même pas le pied pour écouter des MP3, mais pour les son d'erreurs ça marche bien.
On peut également exporter les imprimantes locales sur la machine distante.
Tout ceci est fait au niveau du client au moment de la connexion.
À quand le partage de bureau facile et rapide dans Gnome ?
Pourquoi DANS Gnome ?
Personnellement j'utilise RDP que ce soit sous Windows ou sous Unix/Linux. Avec xrdp en serveur sous les Unix/Linux.
C'est accessible de partout, c'est rapide et ça marche bien.
Après si la personne veut lancer Gnome depuis son écran d'accueil Xrdp, pas de soucis.
Laisse tomber. Alsa ne fait pas de multiplexing (ce n'est pas son rôle),
Il y a 5 API de multiplexing dans ALSA. Dont trois ont fonctionné à un moment donné(dmix, Virtual Device et SoftVol) et une interface pour le multiplexing hard si la carte le supporte (et que le device est pas en lock exclusif par Pulse Audio, parce que sinon tu risques de crasher l'audio, à moins que les fréquence d’échantillonnage soient rigoureusement identiques)
alsa ne permet pas d'utiliser plusieurs cartes sons en redirigeant dynamiquement certains flux sur une carte et d'autres sur l'autre
Si si aussi. Enfin dans le code il y a des pages entières pour passer le flux qui rentre sur une interface alsa d'un device alsa-driver (virtuel ou non) à un autre. La seule utilisation connue (mais pas documenté pour autant) c'est le passage de HDA au device définitif suivant qu'on lise un DVD ou non.
ALSA ne permet pas de régler le volume par flux.
softvol permettait de créer un device nommé par application et donc de régler le volume par flux. En fait il permettait même de créer plusieurs device par application et de faire que la seconde instance d'audacity n'avait pas le même volume que la première (par exemple)
ALSA n'est qu'une API pour exposer la couche hardware.
Non ca c'est Alsa-Hcontrol qui est une sous partie de Alsa-driver, qui lui même n'est pas à proprement parler le framework Alsa, juste une interface coté hard.
Dire que ALSA est bien suffisant c'est déjà un manque de connaissance en soi
C'est à dire que là, la personne qui manque de connaissance c'est pas forcément celle qui déclare qu'Alsa est suffisant. Sur le papier Alsa est largement suffisant, maintenant si on pouvait avoir la doc et des API qui ne sont pas cassées à chaque mise à jour ca ferait plaisir.
ESD, Arts et Pulseaudio aurait été créés juste parce que les gens n'ont pas pensé à utiliser Alsa
Déjà ESD c'est sorti pour OSS, Alsa n'existait pas à l'époque. Ensuite Arts a été écrit pour le projet KDE, parce que tous les systèmes sur lesquels KDE tournent ne possèdent pas Alsa et qu'il fallait une interface générique. (Mais bon au début Arts sur Linux coté kernel c'était quasiment juste une GUI pour piloter Alsa). Quand à PulseAudio il jette bébé avec l'eau du bain en bloquant les fonctionnalités realtime, resync et timer. C'est pas de sa faute, il est en pur userland donc forcément...
Rappelons que Pulseaudio n'est pas sorti ex-nihilo comme une idée à Lennarts
Ca ne change rien au fait que Pulse Audio ne résout aucun problème, il balaye la poussière sous le tapis. Madame Michu est contente parce que ca lui permet simplement d'avoir à la fois le son de sa video et les bruits de son Linux, mais pour toute personne qui souhaite faire du son de façon un peu propre ça reste une abomination.
Néanmoins les attaques que tu donnes impliquent déjà un haut niveau d'accès
A moins que ton serveur de logs soit accessible depuis l'extérieur (et là il y a un vrai problème), le niveau d'accès dans tous les cas est le même : avoir accès à une machine sur la même branche réseau. Faire un poisonning ARP c'est une ligne de script.
spammer le serveur de syslog non.
Le truc c'est que la solution de Lennart va pas changer grand chose. A la limite, si j'ai envie de saturer/forcer une rotation sur un serveur de log chez quelqu'un, je n'ai qu'à ouvrir des milliers de connexions ssh par seconde et à les couper brutalement, ou à réclamer des milliers de pages web inexistantes sur un site. Et là j'ai même pas besoin d'être sur la même branche réseau. Suivant la sécurité du réseau ça passera ou pas.
monter une petite pki, ou un système à la ssh n'est pas très complexe à mettre en oeuvre
En externe non, en interne (ie dans le programme de syslog lui même) je vois pas l’intérêt. Ca prend effectivement 10 secondes de dire à ton serveur de log de n'écouter qu'en lo0 et de dire aux demons distants de monter un tunnel ssh avant de loguer (pour peu que le démon distant en question soit démarré suffisamment tard). Maintenant Lennart invoque une solution en interne, donc soit ca s'appuie sur des systèmes connus (Kerberos, IPSec éventuellement SASL) dont il est client, soit il va falloir coder un service complet d'auth dans le syslog. Et très honnêtement un syslog qui possède son propre service PKI à maintenir et à mettre à jour ....
Bon maintenant Lennart veut que Journal s'appuie sur HAL, ConsoleKIT, SystemD (et donc DBus), un serveur de base de données (j'espère en no-sql parce que les logs c'est pas forcément très structuré), donc rajouter un système d'auth par dessus tout ça, ça doit pas lui faire peur. Ceci dit je serais quand même curieux de voir comment il compte loguer la phase 2 du boot et le dmesg (ou même un crash DBus tient).
Interpreter c'est justement ce que je lui reproche, de remplacer l'ip de l'émetteur par celle du message
Non, il reçoit un message qui possède un contenu dont une section "IP" avec une adresse. Lui il enregistre le message sans y toucher. La seule chose qui intéresse syslog c'est le numéro de processus, le reste tu fais ce que tu veux.
c'est vrai quoi, on peut même pas stocker un binaire à la place de bonnes vieilles lignes de texte dans les logs, c'est inadmissible!
Euh, les syslogers que je connais peuvent tous stocker des binaires. Très pratique pour loguer des tcpdump, des tickets kerberos, des graphs rrdtools ou des emails suspects.
Ben justement, tu peux envoyer n'importe quoi à ton serveur syslog, sans authent ni signature.
Et tu proposes quoi au juste en solution ? Parce que sans vouloir être méchant le moins du monde, ce type de problème d'absence d'authentification on les rencontre à tous les niveaux dans le cadre d'un réseau local. Au niveau ARP (poisonning), au niveau routage (Man in the middle), au niveau IP (spoofing) et enfin au niveau logique.
Même si le programme de Lennart fournit une véritable protection au niveau logique (ce dont très honnêtement je doute, à moins de faire IPSec/Kerberos c'est très difficile d’authentifier une machine de façon non trivialement contournable) pour que ça n'explose pas en deux lignes de scripts, il faudra de toute façon que l'admin réseau mette en place une politique de surveillance assez pointue pour éviter les débordements.
Bizarrement si tu indiques une ip dans le message que tu lui envois, il indiquera celle-ci dans les logs plutôt que celle de ma machine émettrice
Un sysloger se doit de loguer ce qu'on lui envoie, il n'est pas là pour interpréter. Rien n'empêche (en fait c'est même recommandé) de loguer aussi le trafic réseau sensible. A partir de là les recoupements sont possibles.
j'ai vu également des cas avec des injections de caractères d'échappement forçant l'émulateur de terminal à écrire des fichiers.
Comme dans tous les autres programmes, surtout les programmes exécutés par root, des failles peuvent apparaître. Généralement elles sont corrigées assez vite.
Disons que ça marche dans les conditions suivantes
a) Pulse audio fait un lock exclusif du périph Alsa. Tous les utilitaires qui veulent faire du bruit passent par padsp ou mieux par Gstreamer.
b) HAL, ConsoleKIT et DBus sont configurés à la sauce Fedora/Red Hat. Cette sauce n'est pas mauvaise, mais elle n'est pas nécessairement la panacée pour tous les utilisateurs.
c) Les corrections de skew ou de buffer doivent être prise en charge directement par le pilote Alsa ou par pulse-Audio lui même via GStreamer. Toute tentative d'intervention par un programme tiers risque de tout faire partir en sucette.
Donc fondamentalement quand on veut au choix, du JACK, du gapless (oui parceque GStreamer et le gapless...) de la synchro pointue, utiliser les clocks HPET etc. On sort forcément de la notice d'empaquettage de Lennart. (Bon généralement quand on veut un des trucs ci dessus on prend une distrib dans laquelle on peut gicler Pulse Audio facilement.)
Après le choix d'Ubuntu de mettre Pulse Audio tout en essayant de garder la compatibilité avec les fonctionnalités avancés du son sous Linux est discutable. Mais il n'est pas idiot. Pulse Audio a été conçu pour fonctionner dans un cas précis (utilisateur bureautique qui écoute du son en mode "loisir") et son utilisation dans à peu près tous les autres cas est problématique.
[^] # Re: Dis moi ce dont tu as besoin, je te dirai comment t'en passer…
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 2.
Alors en informatique l'auteur du logiciel est celui qui en a écrit les specs, pas le codeur. De plus si tu travailles sous contrat (y compris consulting, CD CDD), même sur des specs que tu as écrites toi même, l'auteur est ton employeur. Pour finir le droit moral en informatique c'est peau de chagrin, pas de droit au repentir ou au retrait, pas de droit sur les adaptations etc. Bref il reste le droit au nom (et une fois de plus dans le cadre d'un contrat ce sera le nom de l'employeur)
[^] # Re: Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 2.
L'exemple que tu prends est loin d'être aussi anodin que tu le penses,
Aujourd'hui quand on prend une distribution Linux, on se retrouve souvent avec Google comme moteur de recherche par défaut, et assez souvent comme page de démarrage.
Est-ce une bonne chose ? C'est ce dont la plupart des utilisateurs ont l'habitude. Donc c'est ce qui dérange le moins les utilisateurs statistiquement. Cependant
- Duck Duck Go est bien meilleur au niveau du respect de la vie privée
- Yahoo avec son système de catalogue est plus adapté pour les grands débutants
- Un meta-moteur custom peut surprendre l'utilisateur, mais permettre des résultats plus pertinents
Donc que fait-on ? On laisse Google, avec la possibilité de changer ?(de plus en plus planquée la possibilité, les barres d'outils étant en voie de disparition dans les navigateurs). On met Duck Duck GO pour le respect de la vie privée avec un bouton bien visible pour passer en mode Google, mais sans aucune explication ? Ou alors on met un petit laius au premier lancement du logiciel en priant pour que la personne le lise et en fasse pas next, next, next.
Même sur le libre on peut faire des choix d'office à la place de l'utilisateur, et ça permettra à l'utilisateur de rentrer plus vite dans le produit. Mais est-ce une bonne idée ?
Les gens veulent Google en moteur de recherche et en page de démarrage. Donc soit on le leur donne sans réfléchir (auquel cas l’intérêt du libre est rigoureusement 0), soit on essaye de les inciter à perdre un automatisme qui ne se justifie pas forcément.
Cette remise en cause des automatismes est nécessaire, même si oui elle casse les pieds au client. Quand on oblige les mots de passe à avoir une certaine taille, quand on les forces à changer de façon significative d'une fois sur l'autre, quand on leur enlève des raccourcis dangereux ou qu'on leur bloque des comportements à risque. Bien sur on casse les pieds à l'utilisateur, et au passage on se casse les pieds à soi aussi. Il ne s'agit pas seulement de chercher à résoudre son problème propre plutôt que le problème de l'utilisateur, mais bel et bien de chercher à créer un environnement fiable et pérenne.
Forcément ça fait grincer les dents des utilisateurs au début, et bien entendu il faut avoir un produit de qualité et qui rend de vrais services pour que le dit utilisateur continue à utiliser notre service/logiciel. Mais généralement ça vaut le coup sur le moyen-long terme.
[^] # Re: Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 6.
Ah mais si tu veux un ordinateur préconfiguré, qui vient avec son abonnement ADSL et son email pré-installé et nominatif, et tous les paramètres choisis d'avance - c'est pas un problème, c'est très facile à faire. Prend par exemple windows 98, il venait avec son navigateur internet, le moteur de recherche plugué sur MSN, il y avait un joli logo "se connecter à internet" qui te permettait d'avoir une connexion MSN assez rapidement pour peu que l'on ait eu un modem et une carte bleue. Bien sur le navigateur c'était IE 5 avec les ActiveX grands ouverts.
Et le libre a ramé, mais alors ramé de chez ramé pour freiner la tendance puis l'inverser. Bonjour la bataille pour que phenix devenu firebird devenu firefox s'impose (Ben oui ton truc il marche pas sur le serveur de ma banque alors je suis retourné sous IE), bonjour la bataille pour limiter les ActiveX, le tout avec l'ART devenu ARCEP qui tapait sur les offres Ordi+abonnement internet+communications pour une mensualité défini sur une durée de 36 mois.
Pourtant c'était vachement plus simple pour le client, il rentrait chez lui, il branchait l'ordinateur, le modem dans la prise et hop il recevait directement des emails à son nom sur sa machine. 0% installation, 100% prison.
Et oui il a fallu expliquer aux gens, leur expliquer pourquoi le truc qui marchait moins bien et qui était plus compliqué était mieux pour eux. Dieu merci à l'époque de Windows 98 les gens étaient suffisamment en colère contre Microsoft pour nous écouter. Apple était pas encore complètement reparti et les gens cherchaient des alternatives.
Maintenant c'est clair que la machine pré-configurée ras la gueule, avec fichage du client et détermination des services par un tiers c'est le contraire exact du libre. Et la seule parade, vu que l'on va avoir du mal à chopper les accords commerciaux et les designers des logiciels proprio, c'est de pousser les gens à
- Premièrement déterminer précisément ce dont ils ont besoin
- Deuxièmement apprendre à se documenter par eux même
- Troisièmement refuser les solutions toutes faites si elles ne conviennent pas au besoin.
[^] # Re: Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 9.
J'ignore a quel moment on est passé de lire le manuel -> les options ça évite de lire le manuel -> Imagine qu'on doive choisir la taille et la couleur de tous les titres des fenêtres avant de lancer gnome; mais vous m'impressionnez les mecs.
Pourtant je suis pas mauvais en mauvaise foi et en sophismes déplacés, mais là chapeau bas.
Tout d'abord devoir lire un manuel pour tirer parti pleinement du LL ne veut en aucun cas dire devoir apprendre par coeur l'ensemble des pages du manuel concerné avant de pouvoir lancer le programme. La grosse majorité des logiciels libres ont un comportement par défaut relativement acceptable. La nécessité de lire le manuel se trouve surtout quand on a besoin de sortir de ce comportement par défaut. Même Apache-Tomcat, qui est à mon sens la pire des horreurs jamais créé en terme de fichier de config, permet de lancer des servlets en quelques minutes après l'install (sur 127.0.0.1:8080 d'accord). Ca fait quand même un moment que les configs imbitables à coup de m4 et de make, merci sendmail, ont disparues.
Maintenant les configs par défaut, les logiciels proprios en ont aussi. Et vu que les logiciels proprios forcent l'utilisateur a utiliser des solutions prédéfinies (noyeau fixé, pilotes fixés, interfaces fixés etc.) et qu'ils ont des équipes de dingues au niveau de l'UI, les solutions par défaut des logiciels propriétaires seront toujours meilleure que les solutions par défaut des LL.
Peut importe que l'on doivent se palucher le fichier de config à la main, ou que l'on ait une belle interface graphique avec des gors boutons, à un moment ou à un autre il va falloir apprendre ce que ca veut dire activer le snmp v3. Et ça, ça passe par lire le manuel. Même un utilisateur lambda il doit savoir un minimum de chose, par exemple à l'installation d'office, si il choisit le mode de configuration manuel on va lui demander si il veut activer la prise en charge de la police universelle et si il veut sauvegarder au format OpenXML ou OpenDocument.
Et là soit il se renseigne, soit il y a des chances non négligeables que ses fichiers ne soient pas lisibles par ses petits camarades.
Si il prend l'installation par défaut, son Word ne s’intégrera pas forcément comme il faut avec la dataroom, et son format de sauvegarde ne sera pas forcément compatible avec celui des Office plus ancien.
Bref les configs par défaut ça a des limites, et ces limites sont beaucoup plus strictes si on est sur du proprio que sur du LL. C'est à mon sens à aujourd'hui le seul avantage tangible du LL. Pour tirer parti de cet avantage il faut lire le manuel et mettre les mains dans le cambouis au moins un peu. Si on est pas prêt à faire ça, le logiciel proprio est meilleur.
[^] # Re: Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 5.
Il ne sont pas utilisateurs de Postfix, ils sont utilisateur du service qui va avec. C'est à l'utilisateur du serveur et pas du service de lire le manuel. Si il y a un problème au niveau 2 (donc au niveau du service) c'est à moi de le résoudre, et donc à moi de lire la doc.
Les utilisateurs eux reçoivent une doc sur comment configurer leur client mail avec mes serveurs, et la plupart y arrivent tout seul comme dans grands.
Ceci étant mon point reste valable, à savoir que le fait que j'utilise un logiciel libre m'apporte quelque chose, mais qu'il n'apporte strictement rien à mes clients. C'est toujours celui qui lit la doc qui peut tirer parti du LL.
[^] # Re: Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 8.
Non on perd du temps, au final mon postfix qui fait exactement ce que je demande, exactement comme je le veux avec les logs au format que je souhaite et les authentifications qui peuvent gérer ses deux bouses ultimes niveau TLS/SSL que sont Mail.app et Outlook m’économisent des heures de maintenance tous les mois.
Alors c'est vrai que j'aurais pu prendre un truc tout packagé et dire à mes clients "Ah oui avec Outlook 2003 ça marche pas" et "Mail.app interprète les déconnexion comme une erreur de mot de passe, fermez tout et retapez vos mot de passe encore une fois". Mais je préfère la solution actuelle. Je pense que mes clients aussi.
Non l'insulte c'est de pourrir un forum avec des questions triviales qui prouvent que l'on a même pas pris trente secondes à chercher la réponse par soi-même. RTFM est juste la réponse à cette insulte.
Non ça veut juste dire que la personne qui a conçu le logiciel te laisse toutes les possibilités pour sa mise en place. Mais plus tu as de choix dans ta config, plus tu as de paramètres à valider avant de pouvoir passer à un système fonctionnel.
Neuf fois sur dix, quand une application marche "tout seul", c'est l'homme qui se retrouve au service de la machine. Personnellement une personne qui fait ce qu'elle veut, comme elle veut au moment ou elle veut j'appelle pas ça un domestique. Seulement la première étape quand on veut avoir quelque chose à son service c'est de lui donner des directives. Si on saute cette étape on a un truc qui fait peut être des choses intéressantes, mais qui n'est pas vraiment à notre service.
En quoi ? Si on prend le fonctionnement de base sans y toucher, sans chercher à mettre une seule seconde les mains dans le cambouis comment le logiciel libre pourrait-il battre les hordes de designers d'interface et de graphistes de MS ou de Apple. Au mieux on aura des comportement différents qui plairont plus à une partie de la population que les comportements par défaut de Mac ou de Windows, au pire (et c'est malheureusement ce vers quoi le desktop semble glisser) on aura une tentative de copie carbone d'une interface ou l'autre.
Pas du tout non, ce que je dis c'est que le libre (en tant qu'outil) n'apporte rien à une personne qui ne veut pas mettre un minimum les mains dans le cambouis, et qu'à partir de là cette personne ne trouvera aucun intérêt à passer au libre. Bref, une personne qui se moque de la technique (en fait qui est techniquophobe, dans le sens ou elle vomit vert fluo quand on lui présente le manuel de l'utilisateur) n'a aucun intérêt à être sous Linux ou sous BSD. Elle sera bien mieux sous Mac ou sous Windows le jour ou elle aura un besoin spécifique. Là elle paye, elle branche/installe et ça marche. Pas besoin de se demander si le matériel est bien supporté ou si le package 64 bits est stable.
[^] # Re: Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 5.
_Il y a manuel et manuel. Les pages mans sont des manuels de référence complètement inutilisable quand tu débutes. _
Je vais avoir du mal à pas faire passer ça pour un gros troll, mais si sous certaines distribs Linux ce que tu dis est vrai, sous FreeBSD tu peux parfaitement partir de 0 avec juste le docbook dans une main et les man pages dans l'autre. Et sous OpenBSD ils poussaient même le vice jusqu'à te renvoyer dès le début du manuel vers Understanding IP addresses http://holdenweb.com/static/docs/3comip.pdf (à lire absolument).
Bien sur à un moment ou à un autre il faudra passer sur une doc un peu plus conséquente, mais on peut aller vraiment loin juste avec la doc de base sous BSD.
# Malheureusement tu es passé à coté du plus gros défaut des LL.
Posté par Kaane . En réponse au journal le confort contre la liberté. Évalué à 10.
Le plus gros défaut des logiciels libres c'est qu'on dispose de l'ensemble des outils pour en faire ce que l'on veut.
Ça implique un certain nombre de choses :
a) Déjà il faut savoir ce qu'on veut. Là tu as perdu 50 à 60% du marché.
b) Ensuite il y a le problème de disposer des outils. Généralement ça implique de passer un peu de temps pour s'approprier ces outils, ce qui induit généralement le fait de devoir LIRE LE MANUEL (taaaa dan <---- accord musical sinistre). Même sur les forums de ces excentriques de libriste (moins de 3% de la population totale) RTFM est perçu comme une insulte personnelle, et la plupart des questions des dits forums ont été posées tellement de fois qu'il suffit généralement de 8 seconde de recherche sur internet pour avoir la réponse. Si j'en crois les statistiques, on doit déjà s'être amputé d'un bon 98,5% du marché.(Et la je suis large, ça voudrait dire que la moitié des libristes lisent les man pages et les info pages des logiciels qu'il utilisent - non suivre les howto en mode copier-coller ne compte pas)
c) Finalement il y a le problème de faire. Ça implique du temps (et même parfois un budget dédié dans le cadre professionnel). C'est à dire des gens qui vont prendre de leur temps pour résoudre un problème qui n'est pas pris en charge de base par leur installation pour obtenir un résultat qui colle exactement à la virgule près à leur besoin. Ça va d'écrire un script d'init différent de celui fourni avec le paquet à coder une application complète, respectueuse des standards et fiable.
Quel est le pourcentage de libristes qui arrive jusqu'au c) ? Qui peut faire un ps x depuis l'utilisateur root et expliquer ligne à ligne à quoi correspond ce qu'il voit, à quoi ça sert, et comment le configurer ?
En bref quel est le pourcentage de "libristes" qui auraient exactement la même utilisation de leur machine personnelle si ils étaient sous Windows ou sous Mac OS X ? Pour les machines desktop ça doit être la grosse majorité, je dirais au pif un bon 70-80% (mesure pifométrique basé sur le fait que je suis un professionnel sur le sujet attendu que j'ai organisé trois install party et que j'ai filé un coup de main à un LUG une fois pour leur serveur mail.) Sur les serveurs ça doit pas être bien brillant non plus.
Bref les gens ne veulent pas lire le manuel, veulent que ça marche "tout seul" (même si du coup ils ne peuvent pas choisir la direction de cette marche) et ne veulent pas passer du temps à refaire mieux un truc qui marche presque assez bien pour eux. Donc le libre n'a strictement rien à leur apporter. A partir de là pourquoi se casseraient-ils les pieds à enlever l'O.S fourni avec leur ordinateur.
# C'est possible mais...
Posté par Kaane . En réponse au journal Mutualiser ses abonnements en logement collectif. Évalué à 10.
Tout d'abord, sur le tarif "entreprise" vs tarif particulier :
Clairement le tarif jaune, pour les consommations élevées est plus intéressant que le tarif bleu, mais pour un particulier ça se discute vraiment. Un tarif bleu arrive chez toi, dans un joli tableau électrique derrière un beau compteur le tout ayant été validé au moins une fois (des fois il y a longtemps, d'accord) par un organisme dit "le consuel".
Le tarif jaune arrive dans un local réservé de ton fournisseur, et tout le reste du raccord c'est ton problème. C'est donc à toi de tirer les cables, d'équilibrer les phases (j'y reviens), de séparer les consommations et de payer la facture. Tu es également légalement responsable de ta partie de l'installation, ce qui implique une assurance et une maintenance de l'existant.
Bref tu te poses en fournisseur de service, et sur l'électricité il y a pas mal de responsabilité qui viennent avec.
De plus les tarifs jaunes coûtent souvent beaucoup plus cher en terme d'abonnement, et une partie des frais nécessaire au passage d'un tarif à l'autre sont imputables au client. Par exemple si il faut remplacer deux ou trois cables existant par un seul gros cable pour le tarif jaune, ça peut faire mal.
Grosso-modo quand on installe un tarif jaune, il faut :
a) dédier un local d'alimentation à la répartition de l'électricité. Sauf cas particulier ce local doit être distinct du point d'arrivé de ton fournisseur. Dans ce local il faut mettre :
Équilibrer les phases ça veut dire s'arranger pour que le disjoncteur général ne claque pas quand on arrive à un tiers de la puissance. En effet le tarif jaune va arriver en triphasé, et à moins que tu ne passes dans tous les apparts pour vérifier tous les appareils électriques, il va falloir garder ce triphasé. Ca implique tout d'abord de générer un neutre, puis de se lancer dans une installation électrique complexe et couteuse pour que madame Michu qui déciderait de lancer la machine à laver, le séche linge et le chauffage en même temps
- ne disjoncte pas si elle est dans sa tranche de puissance
- ne fasse pas disjoncter le général si madame michmoch et madame michdule ont eu la même idée
- ne parasite pas madame michtruc qui veut juste regarder la télé.
En d'autres termes s'arranger pour que tous les habitants de l'immeuble reçoivent un courant sinusoïdal propre avec 3 phases capable de fournir la puissance demandée à chaque instant. Et l'air de rien c'est pas si évident que çà.
b) Le câblage devenant ta responsabilité légale, il va falloir t'assurer qu'il convient bien à la nouvelle installation. Généralement ca implique un électricien compétant, un passage du consuel, plusieurs coupures voire la mise en place d'une électricité de chantier avec dérivation et tout le toutim.
c) Il va également falloir que tu t'occupes de mettre en place les boîtiers de consommation, qui doivent obligatoirement être aux normes francaise d'une part, et accessibles à tout moment par l'usager final d'autre part.
Voilà pour le coté chantier à proprement parlé.
Ensuite il faut gérer les consommations, les facturations, les paiements, les demandes d'augmentation de puissance d'untel ou unetel, faire le relevés quand il y a changement d'utilisateur final etc. Amusant
Et enfin il faut payer les factures tarif jaune. Parce que le tarif jaune il peut être coupé beaucoup plus facilement que le bleu (même si dans la pratique les fournisseurs sont coulants pour les grosses factures qui ne leur demande pas autant de boulot que les particuliers). Ceci dit si un de tes habitants se retrouve dans une sale situation (genre monsieur est partie avec une danseuse, laissant madame et ses deux enfants derrière lui) ça peut vite poser un problème, surtout si le chauffage est électrique. Monsieur le juge ou les services sociaux t'interdiront de couper l'abonnement, et avec ton tarif jaune tu vas être bien mari pour le réduire en amont et ainsi diminuer tes coûts. Si dans l'immeuble il y a 6 occupants dont toi, tu vas te retrouver à avoir le choix entre payer un tiers de la facture tout seul de ta poche, ou priver l'ensemble de l'immeuble d'électricité avec les conséquences légales que ça peut avoir.
Bref pour 150€ par an et par abonnement et 0,036€ ça va être dur de gérer tout çà...
# Gnomes et Trolls du vendredi ! Eh bien lutin de bord d'elfe de mer....
Posté par Kaane . En réponse au journal Petite réflexion sur le futur du desktop. Évalué à 9.
Les problèmes de gnome-shell tout d'abord.
Gnome 3 avec Gnome-shell est en train de se prendre de plein fouet la loi du 90/90 à savoir :
90% des utilisateur veulent absolument faire au moins une chose dont 90% des utilisateurs n'ont strictement rien à foutre. De madame Michu qui veut regarder ses emissions sur la redif TF3 à Jean-Kevin qui a vraiment envie d'avoir deux cartes wifi distinctes sur sa machine, toutes les deux actives en même temps.
Quand au
dockappsdockletsdeskletsextensions, je ne veux pas être méchant mais si on oublie les inénarrables bidule de météo qui clignotent, la plupart des "extensions" de Gnome Shell consistent pour l'instant soit en des réimplémentation des anciennes interfaces, soit carrément des extensions qui suppriment ou masquent des fonctionnalités de Gnome Shell.Bref on utilise une surcouche logicielle pour enlever une autre surcouche logicielle qui rajoute des fonctionnalités/comportement qui sont loin de faire l’unanimité. Alors bon on sait depuis Gstreamer que Gnome n'a pas peur d'en tenir une bonne surcouche, mais là quand même si on prend toutes les extensions et qu'on les installe, on se retrouve avec un Gnome-Shell maquillé en Gnome2, une applet météo et un truc qui s’appelle zeitgeist, qui ressemble à Beagle, mais pas trop (les paris sont ouvert sur la viabilité du truc, il a déjà changé de nom deux fois), le tout pour à peine la consommation CPU/RAM/Video d'un cluster de station IRIX en pleine analyse des collisions du LHC.
Ceci étant, oui les gens passeront à Gnome 3 + Gnome Shell au bout d'un moment. Déjà parce que je ne pense pas qu'un fork de Gnome2 arrive à suivre le rythme de façon soutenue, deuxièmement parce que les Linuxiens du desktop ils aiment bien les trucs trop joli à regarder même si ça ne leur apporte rien et enfin parce que faire des packages GTK2+Gnome2+interfaces dbus/ systemd/HAL qui collent avec une distrib donnée c'est déjà pas évident (CF Slackware), mais alors faire la même chose sur une distrib qui s'appuie fortement sur Gnome 3 sans rien casser ca doit être franchement coton.
Vu la façon dont les outils systèmes gnome s'enfoncent de plus en plus profondément dans la config de base du système, il va bientôt falloir prendre des distribs spécialisées KDE (ou en tout cas avec aussi peu de GTK/Gnome que possible) pour avoir une chance de pouvoir compiler/installer une version Gnome non "canon". Bref quand on aura le choix entre Gnome-Shell ou LFS, le choix sera vite fait.
Maintenant, hypothèse qui n'a pas été évoquée, mais qui reste réelle : Et si gnome-shell finissait par claquer entrainnant Gnome3 dans sa chute.
C'est peu probable quand même, vu Red Hat qui pousse derrière (Mais bon Red Hat, quand il s'agit de balancer à la poubelle la techno phare de la release précédente ça ne leur fait pas vraiment peur.) Néanmoins entre KDE qui ne fait pas que des heureux, Gnome qui dégoutte même ses fans les plus fidèles, XFCE et LXDE qui sont presque mais pas suffisant, il y a aujourd'hui pour la première fois une vraie place à prendre pour un outsider. Et dans le monde du libre, quand il y a une place à prendre...
[^] # Re: Oui mais...
Posté par Kaane . En réponse au journal Gnome 3.4 et les machines virtuelles. Évalué à 2.
Pour la webcam je ne crois pas que ce soit facilement possible, pour les deux autres RDP fournit les moyens d'exporter les disques locaux sur la machine distante et de jouer le son de la machine distante soit en local, soit en distant.
Ceci étant c'est quand même pas le pied pour écouter des MP3, mais pour les son d'erreurs ça marche bien.
On peut également exporter les imprimantes locales sur la machine distante.
Tout ceci est fait au niveau du client au moment de la connexion.
[^] # Re: Oui mais...
Posté par Kaane . En réponse au journal Gnome 3.4 et les machines virtuelles. Évalué à 1.
À quand le partage de bureau facile et rapide dans Gnome ?
Pourquoi DANS Gnome ?
Personnellement j'utilise RDP que ce soit sous Windows ou sous Unix/Linux. Avec xrdp en serveur sous les Unix/Linux.
C'est accessible de partout, c'est rapide et ça marche bien.
Après si la personne veut lancer Gnome depuis son écran d'accueil Xrdp, pas de soucis.
[^] # Re: Bientôt les journaux /dev/null?
Posté par Kaane . En réponse au journal Danielle Mitterrand bronsonisée !. Évalué à 6.
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
Euh, oui j'utilise Debian, mais comment le savez-vous ?
[^] # Re: systemd
Posté par Kaane . En réponse au journal Lennart casse les logs!. Évalué à 10.
Il y a 5 API de multiplexing dans ALSA. Dont trois ont fonctionné à un moment donné(dmix, Virtual Device et SoftVol) et une interface pour le multiplexing hard si la carte le supporte (et que le device est pas en lock exclusif par Pulse Audio, parce que sinon tu risques de crasher l'audio, à moins que les fréquence d’échantillonnage soient rigoureusement identiques)
Si si aussi. Enfin dans le code il y a des pages entières pour passer le flux qui rentre sur une interface alsa d'un device alsa-driver (virtuel ou non) à un autre. La seule utilisation connue (mais pas documenté pour autant) c'est le passage de HDA au device définitif suivant qu'on lise un DVD ou non.
softvol permettait de créer un device nommé par application et donc de régler le volume par flux. En fait il permettait même de créer plusieurs device par application et de faire que la seconde instance d'audacity n'avait pas le même volume que la première (par exemple)
Non ca c'est Alsa-Hcontrol qui est une sous partie de Alsa-driver, qui lui même n'est pas à proprement parler le framework Alsa, juste une interface coté hard.
C'est à dire que là, la personne qui manque de connaissance c'est pas forcément celle qui déclare qu'Alsa est suffisant. Sur le papier Alsa est largement suffisant, maintenant si on pouvait avoir la doc et des API qui ne sont pas cassées à chaque mise à jour ca ferait plaisir.
Déjà ESD c'est sorti pour OSS, Alsa n'existait pas à l'époque. Ensuite Arts a été écrit pour le projet KDE, parce que tous les systèmes sur lesquels KDE tournent ne possèdent pas Alsa et qu'il fallait une interface générique. (Mais bon au début Arts sur Linux coté kernel c'était quasiment juste une GUI pour piloter Alsa). Quand à PulseAudio il jette bébé avec l'eau du bain en bloquant les fonctionnalités realtime, resync et timer. C'est pas de sa faute, il est en pur userland donc forcément...
Ca ne change rien au fait que Pulse Audio ne résout aucun problème, il balaye la poussière sous le tapis. Madame Michu est contente parce que ca lui permet simplement d'avoir à la fois le son de sa video et les bruits de son Linux, mais pour toute personne qui souhaite faire du son de façon un peu propre ça reste une abomination.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . En réponse au journal Lennart casse les logs!. Évalué à 5.
A moins que ton serveur de logs soit accessible depuis l'extérieur (et là il y a un vrai problème), le niveau d'accès dans tous les cas est le même : avoir accès à une machine sur la même branche réseau. Faire un poisonning ARP c'est une ligne de script.
Le truc c'est que la solution de Lennart va pas changer grand chose. A la limite, si j'ai envie de saturer/forcer une rotation sur un serveur de log chez quelqu'un, je n'ai qu'à ouvrir des milliers de connexions ssh par seconde et à les couper brutalement, ou à réclamer des milliers de pages web inexistantes sur un site. Et là j'ai même pas besoin d'être sur la même branche réseau. Suivant la sécurité du réseau ça passera ou pas.
En externe non, en interne (ie dans le programme de syslog lui même) je vois pas l’intérêt. Ca prend effectivement 10 secondes de dire à ton serveur de log de n'écouter qu'en lo0 et de dire aux demons distants de monter un tunnel ssh avant de loguer (pour peu que le démon distant en question soit démarré suffisamment tard). Maintenant Lennart invoque une solution en interne, donc soit ca s'appuie sur des systèmes connus (Kerberos, IPSec éventuellement SASL) dont il est client, soit il va falloir coder un service complet d'auth dans le syslog. Et très honnêtement un syslog qui possède son propre service PKI à maintenir et à mettre à jour ....
Bon maintenant Lennart veut que Journal s'appuie sur HAL, ConsoleKIT, SystemD (et donc DBus), un serveur de base de données (j'espère en no-sql parce que les logs c'est pas forcément très structuré), donc rajouter un système d'auth par dessus tout ça, ça doit pas lui faire peur. Ceci dit je serais quand même curieux de voir comment il compte loguer la phase 2 du boot et le dmesg (ou même un crash DBus tient).
Non, il reçoit un message qui possède un contenu dont une section "IP" avec une adresse. Lui il enregistre le message sans y toucher. La seule chose qui intéresse syslog c'est le numéro de processus, le reste tu fais ce que tu veux.
[^] # Re: c'est lumineux
Posté par Kaane . En réponse au journal Lennart casse les logs!. Évalué à 1.
Euh, les syslogers que je connais peuvent tous stocker des binaires. Très pratique pour loguer des tcpdump, des tickets kerberos, des graphs rrdtools ou des emails suspects.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . En réponse au journal Lennart casse les logs!. Évalué à 4.
Et tu proposes quoi au juste en solution ? Parce que sans vouloir être méchant le moins du monde, ce type de problème d'absence d'authentification on les rencontre à tous les niveaux dans le cadre d'un réseau local. Au niveau ARP (poisonning), au niveau routage (Man in the middle), au niveau IP (spoofing) et enfin au niveau logique.
Même si le programme de Lennart fournit une véritable protection au niveau logique (ce dont très honnêtement je doute, à moins de faire IPSec/Kerberos c'est très difficile d’authentifier une machine de façon non trivialement contournable) pour que ça n'explose pas en deux lignes de scripts, il faudra de toute façon que l'admin réseau mette en place une politique de surveillance assez pointue pour éviter les débordements.
Un sysloger se doit de loguer ce qu'on lui envoie, il n'est pas là pour interpréter. Rien n'empêche (en fait c'est même recommandé) de loguer aussi le trafic réseau sensible. A partir de là les recoupements sont possibles.
Comme dans tous les autres programmes, surtout les programmes exécutés par root, des failles peuvent apparaître. Généralement elles sont corrigées assez vite.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . En réponse au journal Lennart casse les logs!. Évalué à 9.
Disons que ça marche dans les conditions suivantes
a) Pulse audio fait un lock exclusif du périph Alsa. Tous les utilitaires qui veulent faire du bruit passent par padsp ou mieux par Gstreamer.
b) HAL, ConsoleKIT et DBus sont configurés à la sauce Fedora/Red Hat. Cette sauce n'est pas mauvaise, mais elle n'est pas nécessairement la panacée pour tous les utilisateurs.
c) Les corrections de skew ou de buffer doivent être prise en charge directement par le pilote Alsa ou par pulse-Audio lui même via GStreamer. Toute tentative d'intervention par un programme tiers risque de tout faire partir en sucette.
Donc fondamentalement quand on veut au choix, du JACK, du gapless (oui parceque GStreamer et le gapless...) de la synchro pointue, utiliser les clocks HPET etc. On sort forcément de la notice d'empaquettage de Lennart. (Bon généralement quand on veut un des trucs ci dessus on prend une distrib dans laquelle on peut gicler Pulse Audio facilement.)
Après le choix d'Ubuntu de mettre Pulse Audio tout en essayant de garder la compatibilité avec les fonctionnalités avancés du son sous Linux est discutable. Mais il n'est pas idiot. Pulse Audio a été conçu pour fonctionner dans un cas précis (utilisateur bureautique qui écoute du son en mode "loisir") et son utilisation dans à peu près tous les autres cas est problématique.