2) leur code ne serait pas commité s'ils refusent les règles (libre à eux de forker s'ils pensent que >c'est la bonne solution).
Et c'est là que le bazard arrive, justement, genre, je sais pas, les dernières évolutions de gnome et les forks qui en découlent?
Au final, même le dev en bazard n'évite pas le fork, parce que tout connement, peu importe la méthode de dev, il y a toujours quelqu'un ou une minorité qui a l'ascendant sur la communauté… comme Linus Torvalds l'a sur Linux (et Lennart sur systemd? aborder cet outil finira par donner le droit au point godwin huuhu)
Mais certaines grandes lignes pourraient devenir communes et on verrait apparaître des standards de >fait.
Les distros obéissent à ce point pour certaines choses:
_ redhat et ses filles => rpm
_ debian et ses filles => deb
_ toutes celles que je connais (pas besef) => Xorg
Mais tout ça n'empêche pas que le bazard ou la cathédrale m'avaient toujours semblé s'appliquer au dev d'un seul logiciel? Pas d'un OS complet et des multitudes de logiciels qu'il inclue, et c'est la "faute" des dev qui ont tous différents besoins… Je me vois mal obliger les dev de firefox à utiliser telle librairie gérant la sérialisation plutôt que boost::serialization, par exemple.
Ben, pour autotool, perso, j'ose pas apprendre à m'en servir.
Dès que je regarde le contenu de ces choses, mon PC mets une musique d'outre-tombe, la lumière diminue et prends des reflets de rouge sang, ma chaise et mon velux claque…
CMake, j'avais peur aussi. Mais quand j'ai regardé un fichier la première fois, aucune ambiance inquiétante ne s'est déclenchée, alors j'ai même trouvé et résolu le problème que je cherchais en moins de 10 minutes.
Avec les récents développements de Gnome3, Unity, systemd (etc.), on peut se demander si le modèle du >bazar amène autre chose que du bazar…
il suffit de remanier la phrase pour comprendre sa pensée:
on peut se demander si le modèle du bazar amène
==> amènent-ils
Ce qui nous donne: "les récents dév […] amènent-ils du bazard?
Traduction et super raccourci trollesque:
Les récents dév de […], c'est le bordel
(perso, j'en sais rien, j'en utilise aucun )
Il y a des gens qui vivent à 10m d'une voie ferrée. Lequel est le plus chiant? Je vote pour la voie ferrée.
Idem pour les autoroutes et encore pire pour les aéroports.
Continuons sur le fait que le vent dans les arbres, ça fait du bruit aussi, et aux dernières nouvelles, les vaches, poules (surtout les coqs xD), moutons et ânes, ça fait un boucan du diable. Je n'ai pas évoqué les chiens…
Entre toutes ces "nuisances" que l'on peut trouver à la campagne et le bruit régulier, que l'on finit donc par oublier, des éoliennes, l'argument sonore me parait peu pertinent.
Ca me fait toujours penser aux citadins qui débarquent en campagne et portent plainte contre les église pour tapage… s'ils veulent du silence, mais qu'ils se crèvent donc les tympans!
Au passage, ceux qui habitent à 50m de la côte, par chez moi, ils savent que leur maison c'est du consommable: 50 ans plus tard, la moitié se casse la gueule de la jolie falaise ou elle était perchée mouhahaha (bon, naturellement, ça ne vaut pas pour tous)
A mon très humble avis, les ampoules àlaconsuperchèresquigrillent3foislan sont tout sauf éco (logique/nomique):
ça coûte un pognon monstre à changer, bien plus que les classiques
ça implique très probablement (on est trolledi alors j'ai droit de pas être renseigné très précisément, non? D'autant que quelqu'un les a déjà cités) des traitements chimiques lourds pour les produire
celles de mauvaise qualité nécessitent un temps pour chauffer. Pas très utile dans les lieux de passage (genre les chiottes pour peu qu'on en supprime la collection de magasine pr0nde geek de jacky) ou les couloirs, comparé aux ampoules classiques.
ça grille souvent! J'en ai changé au moins 4 dans ma piaule cette année bordel!!! Combiné au coût en € et en carbone à la prod, je doute que ce soit si "éco".
Pour le reste, au sujet de l'isolation, par exemple, j'aimerai porter à votre attention 2-3 faits:
une fenêtre très isolée va souvent impliquer, au choix, plus de couches de verres, des gaz ou des intercalaires. Chaque couche va améliorer l'inertie thermique de la fenêtre, ok, mais elle va aussi augmenter son opacité, qui résultera en un allumage des lumières plus tôt en hiver.
une bâtisse très isolée (qui signifie que la température passe mal d'un sens comme de l'autre) implique que l'on chauffera moins en force, mais plus longtemps. Si la bâtisse est utilisée en permanence, comme l'est une usine, par exemple, alors c'est excellent. Sinon, ce n'est pas si sûr: plus il y a d'inertie, plus il faut de temps pour chauffer les murs, donc plus d'énergie.
les énergie dépendant de l'environnement, elles dépendent de là ou l'on habite. En Normandie (du moins sur ses côtes) l'éolien, ça marche sûrement très bien, en revanche, le solaire, j'ai quelques doutes (on se tape des nuages quasi toute l'année)
certaines bâtissent utilisent leur forme, leur placement et leur exposition pour limiter leur consommation électrique. D'ailleurs, ces techniques étaient plus utilisées par "les anciens" que nos parents et grands-parents… Ces techniques reviennent un peu d'ailleurs, dommage qu'on aie perdu une bonne partie de ce savoir.
le bois est plus efficace que l'agglo. Mais il faut l'entretenir à l'aide de produits. Quelle est la toxicité de la lazure par exemple (ceci est une vraie question)?
En gros, je pense que:
chaque environnement favorise une écologie différente (le solaire doit cartonner au sahara, et les pools d'éolienne en mer me semblent être une idée plutôt bonne)
l'usage fait du bâtiment modifie la façon dont il peut être écologique
Conclusion, l'écologie, on cherche tout le temps à nous faire croire qu'il existe une panacée, mais la réalité, c'est que chaque endroit doit trouver sa façon d'être vert. C'est pas en collant des ampoules à la con partout qu'on y arrivera, et éteindre la lumière dans les ascenseurs est une idée stupide, entres autres.
M'enfin, ça change pas que l'idée d'éoliennes libres est bonne. Reste à expliquer dans quels endroits leur utilisation l'est vraiment, histoire d'avoir un rendement réellement utile…
Oui, je sais qu'on peut facilement déplacer le dossier scanné, d'ailleurs je l'ai fait pour voir même si du coup l'utilitaire est devenu moins utile vu qu'on ne peut pas lancer de .desktop :D
debian semble avoir le dernier de packagé, je testerai ça ce soir. Peut-être qu'il y aurait moyen de combiner et le dossier /usr/share/applications pour binder une commande pour les applis X (et garder le mode classique sur un autre binding, vu que je viens d'apprendre qu'on peut passer des paramètres et que pour les kill ça peut effectivement devenir sympa avec un peu de travail)
Pour la config vim: merci je teste ça dès que possible aussi!
Et au sujet du bordel, oui, j'ai constaté que passé les 4 fenêtres mon workspace commence à sérieusement devenir moins évident à contrôler xD
D'un autre côté, sauf pour mon workspace à tout faire, j'ai rarement plus de 3 applis donc bon.
Pour les paramètres, ben… merde, j'étais sûr d'avoir essayé et que ça n'avais pas marché!!! Merci, pour le coup, vrai que ça va être plus pratique.
Cela dis, pour la plupart des outils ligne de commande, je vois absolument aucune utilité. Certains kill (j'aurai plus pensé à killall moi, je ne connaissais pas pkill) ok, mais dans l'ensemble, pas sûr de voir. Après, c'est peut-être encore une manifestation de mon manque de connaissance.
Conclusion: mea culpa pour avoir dis de la merde sur le fait que je ne pensais pas qu'on puisse lui fourguer des arguments et merci pour l'info. Reste a apprendre à manier ça pour voir l'intérêt d'un plus gros pourcentage de la pléthore d'outils en ligne de commande qu'il affiche (parce que les kill, ça fait quand même un très faible %)
Je te rejoins sur le point des terminaux améliorés, je pense aussi que l'on pourrait faire des trucs vraiment sympa (et il faudra donc que je teste ces trucs).
J'ai notamment un truc qui me trotte dans la tête depuis pas mal de temps (et pas seulement des mois) et qui, en soit, semble faisable, encore faut-il le temps de commencer…
En gros, une ligne de commande surmontée d'un explorateur de fichiers tout à fait classique, dont la particularité serait que lorsque l'on écrit un "modèle" de fichiers (genre *.cpp) le modèle de la ligne de commande ET les fichiers lui correspondant adoptent un signe distinctif. Et, tant qu'a faire, quand on sélectionne à partir de la vue graphique (quoiqu'un menu textuel, avec les couleurs termcap, ça serait aussi faisable) un modèle est saisi automatiquement sur la ligne de commande.
Ca serait vraiment utile, mais à chaque fois que je m'y colle, je pense à de nouvelles fonctionnalités et je n'arrive pas à me concentrer sur une base qui fonctionne :S
Accessoirement, il faudrait identifier réellement les points qui sont améliorables sur une ligne de commande… je crois que ce qui m'ennuie le plus, c'est de devoir toujours alterner ls ou l'auto-complétion (qui n'est malheureusement pas en couleur) et les cd quand je me souviens plus des fichiers présents. Il y a aussi les modèles pas toujours rapides à écrire alors que visuellement on pourrait aller plus vite (avec une interface dans le même style que celle de cgdb en somme), ou le fait qu'on ne puisse pas associer aisément un nom de fichier à une action (enfin, si, on peut, via xdg-open et un alias, mais ce serait plus confortable si il n'y avait pas besoin de taper de commande).
Bref, il y a du boulot, mais il faut faire attention à ne pas tomber dans le bloatware comme les interfaces graphiques le font régulièrement.
Si il fait double emploi pour le tiling, à quoi sert-il donc?
Pour le mode onglet? i3 l'a aussi. Il peut même faire un mode "onglets verticaux" (dont je me sert pas, soit dit en passant) et avec l'imbrication de conteneurs et le choix du modèle de chaque, tu peux très bien avec un conteneur père "onglet", des conteneurs fils verticaux/horizontaux, dont des conteneurs petit-fils sont aussi en mode onglet.
Oui, je sais, c'est le bordel, et je n'ai pas encore appris à tout bien manipuler avec i3 (il doit me manquer un truc, mais quoi… P'tet une commande que je n'utilise pas genre sélection du conteneur parent/fils?)
Pour le non pavant, tu peux aussi passer i3 en non pavant: $mod+SPACE fait le travail chez moi (avec $mod==WIN). Naturellement, tu peux aussi imposer le non pavant par défaut sur un espace de travail entier, histoire de pas se prendre la tête.
Pour l'utilisation de i3, j'ai en général un peu moins de workspace que toi, (quoique ça dépende de la machine, si je suis en réseau ou pas et de l'endroit ou je suis…) mais j'utilise surtout :
ncmpcpp (qui ne s'actualise d'ailleurs pas toujours très bien), sachant que j'ai aussi collé un mode pour piloter mpd via mpc…
2-3 consoles de dev
1-2 consoles de config de mon système (j'aime customiser vite et tapper le "su" à chaque fois n'est pas patrick)
xosview (que je dois déplacer à la main, je sais pas pourquoi… pénible d'ailleurs)
un IDE
wesnoth
uzbl / opera (selon l'usage)
Ca doit me faire genre entre 3 et 5 workspaces…
Accessoirement, j'ai encore quelques tracas avec le TWM, peut-être que quelqu'un saura les résoudre?
Déjà, personne ici ne trouve que dmenu, par défaut, c'est ridicule?
Je m'explique avant qu'on m'accuse de troller: je lui reproche 2 choses (qui ne sont pas son problème, en fait, il fait juste son taf, mais je trouve que ça ne suffit pas) :
il affiche par défaut TOUTES les appli dans PATH. Hors, seules les applications X ont un intérêt dans le cas du lanceur pour TWM. Limite, il faudrait juste lister les applis ayant un *.desktop (fichiers qui sont listés dans /usr/share/desktop ce me semble) sauf que bien sûr, on ne peut les lancer.
Peut-être qu'il faudrait créer un dossier contenant des liens symboliques vers les applis du PATH, mais il faudrait pouvoir le mettre à jour automatiquement à chaque install de soft (ça dois être possible mais je sais pas comment faire avec dpkg, quelqu'un à une idée?)
il ne supporte pas les arguments de commande. Ce serait un véritable pied de pouvoir lancer, par exemple (qui est fort pourri dans ce cas-ci, et peut-être même invalide, mais c'est l'esprit l'important) "wesnoth --nosound" en tappant "w --n". Une sorte de bash avec auto-complétion, mais juste avec les programmes cochons en somme (cf 1)
Je trouve aussi que vim fait trop de trucs, de façon trop compliquée. S'il pouvait laisser la gestion de fenêtre au WM, supporter un véritable copier/coller, et si je pouvais trouver comment changer les raccourcis clavier de déplacement pour qu'ils soient les mêmes que ceux de i3 que je trouve plus logiques (jklm au lieu de hjkl, ça évite de bouger un doigt pour rien) je crois que je serai presque comblé (je trouverais bien un truc pour râler après tout).
Note: pour les amoureux des fonds d'écran, on peut même utiliser xplanet ou xphoon :P je le fais pour moins intimider les gens normaux qui regardent mon PC, histoire de passer pour un peu moins cinglé, ce qui échoue lamentablement quand ils voient les peintures de console, et que la souris reste inerte alors que les fenêtres dansent plus vite qu'ils n'ont jamais vu :D
Note2: le fichier de conf monolithique de i3 étant un peu barbarre quand on multiplie les modes, j'ai aussi trouvé une astuce qui consiste à faire un script qui concatène des fichiers. Plus simple à maintenir et à répliquer les parties utiles d'une machine à l'autre (genre le mode audio et le lancement auto de ncmpcpp sur le netbook, il me sert pas: j'ai endommagé ce qui touche au son, alors je le réplique pas)
Bon, c'est sûr, coller un truc dans /usr manuellement, c'est crade. Et en plus c'est ridicule… dans ce genre de cas, mieux vaut penser à /usr/local, ce me semble. Comme ça, y'a que les trucs installés avec make install qui sont mélangés.
Par contre, ton post montre une réflexion intense: je suis un newbie et ton post donne pas l'impression que tu en sois un. Alors sois /usr/local contiens des risques que j'ignore, sois tu n'as pas réfléchi avant de vouloir casser.
Accessoirement, je plussoie alien, et je plussoie aussi le fait que de toute façon, rpm n'est pas supporté par le kernel linux, d'autant que deb est au moins aussi vieux. La seule chose qui fait que rpm serait plus "linuxien" est une reconnaissance comme standard par lsb… sauf que je serai bien curieux de savoir pourquoi l'un plutôt que l'autre, d'autant que si j'en crois les sources que j'ai lues il y a quelques mois (j'ai plus les liens, mais ça se retrouve) deb serait en fait plus ancien (si on était vendredi, j'ajouterais qu'une raison potentielle du choix est le fait que rpm est contrôlé par une entreprise, mais je n'y crois pas trop moi-même)
Et j'ai aussi l'impression de voir plus souvent du debian-based que du fedora-based chez les nouvelles distros, alors au final deb semble plus proche du standard de fait…
Ah. Au fait, NVidia n'utilisais ni deb ni rpm la dernière fois que j'ai essayé ses drivers: seulement un run qui semble faire l'édition des liens… C'est p'tet plus celui la, le format standard de linux, non? Au mois, il marche sur toutes les distro ;)
Hum…
Personnellement, pour découvrir un jeu avec ma debian, j'utilise aptitude => vue par debtags et je vais dans la catégorie que j'ai envie.
Après, pour les catégories du menu "démarrer"… Aucune idée, j'en ai pas ^
Pour ce qui est du coup de gueule sur la packaging, j'ai envie de dire deux choses:
1) ".configure && make && make install" ça me semble dépassé, les dernières compilations que j'ai vues c'était "mkdir build && cd build && cmake .. && make && make install". Au moins la sortie est lisible et la procédure peut fonctionner sur n'importe quel OS.
2) avec cmake, il est possible de générer les paquets pour la plupart des distros en se prenant moins la tête. Moins, mais il faut quand même maintenir la liste des dépendances, et je me demande toujours pourquoi diable boost n'a pas de méta-package chez debian, chose qui oblige les dev à préciser le numéro de version dans le nom du paquet…
Pour le coup, la situation me semble meilleure (ou peut s'améliorer) grâce a cmake (je sais pas si les autres ont un mécanisme idoine aussi simple à gérer), mais il n'empêche que ça reste du boulot de maintenir le cmake pour chaque distro (combien, déjà? 400? de toute façon: trop pour maintenir). Et si le jeu n'utilise pas ce procédé sous prétexte qu'ils utilisent les PPA d'ubuntu, ben… à qui la faute?
Bien sûr, je parle de cmake, et peut-être existe-t-il d'autres mécanismes aussi chiadés (portable et simple), mais je ne les connais pas, alors je vais pas en parler ;)
Après, forcément, cmake n'est pas conforme à la philosophie POSIX, puisqu'il est capable de faire plusieurs choses, mais je ne veux pas lancer un débat sur le fait que ".configure" soit obsolète ou pas (bien que, personnellement, je pige pas comment ça marche, je me dis que d'autres ont peut-être le problème inverse)
Posté par freem .
En réponse à la dépêche OpenBSD 5.2.
Évalué à 5.
C'est surtout que quand on ajoute des fonctionnalités, on risque d'ajouter des bugs, tandis que l'usage d'une version un peu plus ancienne permet d'avoir eu plus de temps pour corriger ceux existants.
Je pense qu'il vaut donc mieux dire qu'ils pensent qu'il vaut mieux avoir un bug connu avec son contournement, plutôt que 2 bugs inconnus (et donc, sans contournement ou potentiellement dangereux pour la stabilité/l'intégrité du système).
Autant je comprend ceux qui t'on déconseillé, autant je ne suis pas d'accord avec les points abordés dans diverses réponses.
Je suis un contributeur jeune (je reprend depuis presque un an un projet* qui était mort depuis… 2006 je crois) mais ce genre d'outil existe, et fonctionne.
Sourceforge et savannah (qui ont la même base logicielle à l'origine) ont effectivement un outil pour que les gens d'un projet demandent des contributions. Et mon expérience actuelle montre qu'en moins de 2 semaines on peut se retrouver avec une 15aine de réponses. Certes, rien ne me dis qu'ils contribueront réellement, et même je doute avoir plus de 3 réels contributeurs dans cette masse, mais il me semble que le fonctionnement est réel.
D'un autre côté, ce projet, même s'il est mort (0 contrib depuis 6 ans) reste quand même à près de 600 dl/semaine. Je récupère donc une base d'utilisateurs non négligeable plutôt que de partir de rien du tout, ça doit aider à attirer (malgré une réécriture totale du code, pour rendre la bête utilisable en natif sur linux).
Autre point, ce logiciel était bien foutu côté simplicité d'utilisation (public visé: joueurs de jdr sur table/papier, pour créer des cartes et plans) et les dev ont donc eu une certaine reconnaissance. Parce que je sais pas pour vous, mais je pense que les logiciels de dessin simple à manier sous linux, à part xpaint (qui est mieux que mspaint mais quand même assez cru) ne sont pas légion.
En fait, même sous windows, on parle toujours de photoshop ou gimp… mais ce ne sont pas exactement des logiciels simples d'accès.
Du coup, le public visé est potentiellement large (tout en étant assez spécifique puisque centré sur les "rôlistes du papier" qui ne sont pas légion).
Après, il est évident que si on veut créer un logiciel, tant qu'aucune version exploitable n'existe, ça va être dur d'avoir des contributions.
Il est aussi évident que si le logiciel en question est YATEFD (Yet Another Text Editor For Developpers) ça va pas attirer: l'offre existante est déjà tellement conséquente.
Dans le cas qui t'intéresse, tu parles d'une fonctionnalité de forge logicielle. Ca implique:
_ public très restreint: techniciens seulement
_ nécessité d'intégration dans l'existant, pas évident vu le nombre de forge existantes
_ fonctionnalité déjà existante
_ nécessité d'auto hébergement, donc d'auto administration, alors que les contributeurs vont vouloir un truc qui permet de renter rapidement sur le projet auquel ils veulent contribuer
Sans vouloir être négatif, je doute effectivement que des gens soient attirés…
Quant au fait que "l'esprit du libre disparaisse"… Il m'a fallu 10 ans pour passer d'utilisateur à contributeur, et encore, je ne me sens pas capable de contribuer du code à ce que j'utilise quotidiennement: Codeblocks, linux, i3, lxterminal, vim, wxwidgets… trop complexe pour moi tout ça. (Il y avait bien flare qui m'intéressais, mais la politique de faire d'abord du code qui tombe en marche avant de refactorer ne m'a pas trop séduit).
Ce n'est pas surprenant qu'il y ait moins de contributions: avant, le libre était moins répandu, ceux qui le connaissaient savaient à quoi s'attendre et on édifié des logiciels impressionnants. Y contribuer du code rapidement n'est clairement pas à la portée de tous, et les petits projets, qui sont accessibles, sont les moins connus. Les gros projets séduisent parce qu'ils sont complets (y font même le café pour certains… et ce, même quand on aime pas le café) mais font peur aux contributeurs potentiels.
Mais pour autant, dire que l'esprit du libre disparaît… le public apprend l'existance de linux, pour certains, ils l'utilisent comme successeur aux logiciels fermés. On ne peut pas attendre de tout ces gens qu'ils contribuent. Il y aura toujours plus de sangsues que de gens pour aider, mais ça ne veut pas dire qu'il y a moins de contributeurs.
*: le projet en question sourceforge.net/projects/autorealm dès fois que ;)
Perso, le pilote nouveau me va bien:
_ support de randr
_ pas de config Xorg à faire (en tout cas sous debian)
Seul "bémol" impossible d'utiliser 2 cartes branchées en même temps (cela dis, c'est précisé sur le site officiel) et il me semble que les jeux 3D soufrent d'une perf moindre, mais pas testé depuis longtemps avec NVidia et/ou windows.
Vu le peu de temps ou je joue à des jeux 3D, je préfère le confort d'un WM qui marche à celui de jeux qui carburent (en attendant les deux en simultané peut-être?).
Et puis tant qu'openMW arrive à fonctionner, donc ça me va.
[^] # Re: Objectivement...
Posté par freem . En réponse au journal A Generation Lost in the Bazaar. Évalué à 1.
Mais tout ça n'empêche pas que le bazard ou la cathédrale m'avaient toujours semblé s'appliquer au dev d'un seul logiciel? Pas d'un OS complet et des multitudes de logiciels qu'il inclue, et c'est la "faute" des dev qui ont tous différents besoins… Je me vois mal obliger les dev de firefox à utiliser telle librairie gérant la sérialisation plutôt que boost::serialization, par exemple.
[^] # Re: trotrotrotro troll !
Posté par freem . En réponse au journal A Generation Lost in the Bazaar. Évalué à 5.
Ben, pour autotool, perso, j'ose pas apprendre à m'en servir.
Dès que je regarde le contenu de ces choses, mon PC mets une musique d'outre-tombe, la lumière diminue et prends des reflets de rouge sang, ma chaise et mon velux claque…
CMake, j'avais peur aussi. Mais quand j'ai regardé un fichier la première fois, aucune ambiance inquiétante ne s'est déclenchée, alors j'ai même trouvé et résolu le problème que je cherchais en moins de 10 minutes.
[^] # Re: Traduction
Posté par freem . En réponse au journal A Generation Lost in the Bazaar. Évalué à 1.
il suffit de remanier la phrase pour comprendre sa pensée:
on peut se demander si le modèle du bazar amène
==> amènent-ils
Ce qui nous donne: "les récents dév […] amènent-ils du bazard?
Traduction et super raccourci trollesque:
Les récents dév de […], c'est le bordel
(perso, j'en sais rien, j'en utilise aucun )
[^] # Re: si tu la joues formelle
Posté par freem . En réponse au journal Linux Lite : comme des connards.. Évalué à 1.
Hé bien tu sais comment contribuer un paquet à debian alors :P
Compilation, packaging, envoi au mainteneur, je suis sûr qu'ils seront preneurs.
[^] # Re: Un test simple
Posté par freem . En réponse au journal Linux Lite : comme des connards.. Évalué à 1.
/me se demande ce qu'ils ont fumé…
[^] # Re: niveau sonore en activité ?
Posté par freem . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 1.
Il y a des gens qui vivent à 10m d'une voie ferrée. Lequel est le plus chiant? Je vote pour la voie ferrée.
Idem pour les autoroutes et encore pire pour les aéroports.
Continuons sur le fait que le vent dans les arbres, ça fait du bruit aussi, et aux dernières nouvelles, les vaches, poules (surtout les coqs xD), moutons et ânes, ça fait un boucan du diable. Je n'ai pas évoqué les chiens…
Entre toutes ces "nuisances" que l'on peut trouver à la campagne et le bruit régulier, que l'on finit donc par oublier, des éoliennes, l'argument sonore me parait peu pertinent.
Ca me fait toujours penser aux citadins qui débarquent en campagne et portent plainte contre les église pour tapage… s'ils veulent du silence, mais qu'ils se crèvent donc les tympans!
Au passage, ceux qui habitent à 50m de la côte, par chez moi, ils savent que leur maison c'est du consommable: 50 ans plus tard, la moitié se casse la gueule de la jolie falaise ou elle était perchée mouhahaha (bon, naturellement, ça ne vaut pas pour tous)
[^] # Re: Ecolo ?
Posté par freem . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 0.
A mon très humble avis, les ampoules àlaconsuperchèresquigrillent3foislan sont tout sauf éco (logique/nomique):
pr0nde geekde jacky) ou les couloirs, comparé aux ampoules classiques.Pour le reste, au sujet de l'isolation, par exemple, j'aimerai porter à votre attention 2-3 faits:
En gros, je pense que:
Conclusion, l'écologie, on cherche tout le temps à nous faire croire qu'il existe une panacée, mais la réalité, c'est que chaque endroit doit trouver sa façon d'être vert. C'est pas en collant des ampoules à la con partout qu'on y arrivera, et éteindre la lumière dans les ascenseurs est une idée stupide, entres autres.
M'enfin, ça change pas que l'idée d'éoliennes libres est bonne. Reste à expliquer dans quels endroits leur utilisation l'est vraiment, histoire d'avoir un rendement réellement utile…
[^] # Re: Cahier des charges incomplet
Posté par freem . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 0.
Oui, je sais qu'on peut facilement déplacer le dossier scanné, d'ailleurs je l'ai fait pour voir même si du coup l'utilitaire est devenu moins utile vu qu'on ne peut pas lancer de .desktop :D
debian semble avoir le dernier de packagé, je testerai ça ce soir. Peut-être qu'il y aurait moyen de combiner et le dossier /usr/share/applications pour binder une commande pour les applis X (et garder le mode classique sur un autre binding, vu que je viens d'apprendre qu'on peut passer des paramètres et que pour les kill ça peut effectivement devenir sympa avec un peu de travail)
Pour la config vim: merci je teste ça dès que possible aussi!
Et au sujet du bordel, oui, j'ai constaté que passé les 4 fenêtres mon workspace commence à sérieusement devenir moins évident à contrôler xD
D'un autre côté, sauf pour mon workspace à tout faire, j'ai rarement plus de 3 applis donc bon.
[^] # Re: Cahier des charges incomplet
Posté par freem . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 0.
Pour les paramètres, ben… merde, j'étais sûr d'avoir essayé et que ça n'avais pas marché!!! Merci, pour le coup, vrai que ça va être plus pratique.
Cela dis, pour la plupart des outils ligne de commande, je vois absolument aucune utilité. Certains kill (j'aurai plus pensé à killall moi, je ne connaissais pas pkill) ok, mais dans l'ensemble, pas sûr de voir. Après, c'est peut-être encore une manifestation de mon manque de connaissance.
Conclusion: mea culpa pour avoir dis de la merde sur le fait que je ne pensais pas qu'on puisse lui fourguer des arguments et merci pour l'info. Reste a apprendre à manier ça pour voir l'intérêt d'un plus gros pourcentage de la pléthore d'outils en ligne de commande qu'il affiche (parce que les kill, ça fait quand même un très faible %)
# terminal amélioré
Posté par freem . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 3.
Je te rejoins sur le point des terminaux améliorés, je pense aussi que l'on pourrait faire des trucs vraiment sympa (et il faudra donc que je teste ces trucs).
J'ai notamment un truc qui me trotte dans la tête depuis pas mal de temps (et pas seulement des mois) et qui, en soit, semble faisable, encore faut-il le temps de commencer…
En gros, une ligne de commande surmontée d'un explorateur de fichiers tout à fait classique, dont la particularité serait que lorsque l'on écrit un "modèle" de fichiers (genre *.cpp) le modèle de la ligne de commande ET les fichiers lui correspondant adoptent un signe distinctif. Et, tant qu'a faire, quand on sélectionne à partir de la vue graphique (quoiqu'un menu textuel, avec les couleurs termcap, ça serait aussi faisable) un modèle est saisi automatiquement sur la ligne de commande.
Ca serait vraiment utile, mais à chaque fois que je m'y colle, je pense à de nouvelles fonctionnalités et je n'arrive pas à me concentrer sur une base qui fonctionne :S
Accessoirement, il faudrait identifier réellement les points qui sont améliorables sur une ligne de commande… je crois que ce qui m'ennuie le plus, c'est de devoir toujours alterner ls ou l'auto-complétion (qui n'est malheureusement pas en couleur) et les cd quand je me souviens plus des fichiers présents. Il y a aussi les modèles pas toujours rapides à écrire alors que visuellement on pourrait aller plus vite (avec une interface dans le même style que celle de cgdb en somme), ou le fait qu'on ne puisse pas associer aisément un nom de fichier à une action (enfin, si, on peut, via xdg-open et un alias, mais ce serait plus confortable si il n'y avait pas besoin de taper de commande).
Bref, il y a du boulot, mais il faut faire attention à ne pas tomber dans le bloatware comme les interfaces graphiques le font régulièrement.
[^] # Re: Cahier des charges incomplet
Posté par freem . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 1.
Si il fait double emploi pour le tiling, à quoi sert-il donc?
Pour le mode onglet? i3 l'a aussi. Il peut même faire un mode "onglets verticaux" (dont je me sert pas, soit dit en passant) et avec l'imbrication de conteneurs et le choix du modèle de chaque, tu peux très bien avec un conteneur père "onglet", des conteneurs fils verticaux/horizontaux, dont des conteneurs petit-fils sont aussi en mode onglet.
Oui, je sais, c'est le bordel, et je n'ai pas encore appris à tout bien manipuler avec i3 (il doit me manquer un truc, mais quoi… P'tet une commande que je n'utilise pas genre sélection du conteneur parent/fils?)
Pour le non pavant, tu peux aussi passer i3 en non pavant: $mod+SPACE fait le travail chez moi (avec $mod==WIN). Naturellement, tu peux aussi imposer le non pavant par défaut sur un espace de travail entier, histoire de pas se prendre la tête.
Pour l'utilisation de i3, j'ai en général un peu moins de workspace que toi, (quoique ça dépende de la machine, si je suis en réseau ou pas et de l'endroit ou je suis…) mais j'utilise surtout :
Ca doit me faire genre entre 3 et 5 workspaces…
Accessoirement, j'ai encore quelques tracas avec le TWM, peut-être que quelqu'un saura les résoudre?
Déjà, personne ici ne trouve que dmenu, par défaut, c'est ridicule?
Je m'explique avant qu'on m'accuse de troller: je lui reproche 2 choses (qui ne sont pas son problème, en fait, il fait juste son taf, mais je trouve que ça ne suffit pas) :
Je trouve aussi que vim fait trop de trucs, de façon trop compliquée. S'il pouvait laisser la gestion de fenêtre au WM, supporter un véritable copier/coller, et si je pouvais trouver comment changer les raccourcis clavier de déplacement pour qu'ils soient les mêmes que ceux de i3 que je trouve plus logiques (jklm au lieu de hjkl, ça évite de bouger un doigt pour rien) je crois que je serai presque comblé (je trouverais bien un truc pour râler après tout).
Note: pour les amoureux des fonds d'écran, on peut même utiliser xplanet ou xphoon :P je le fais pour moins intimider les gens normaux qui regardent mon PC, histoire de passer pour un peu moins cinglé, ce qui échoue lamentablement quand ils voient les peintures de console, et que la souris reste inerte alors que les fenêtres dansent plus vite qu'ils n'ont jamais vu :D
Note2: le fichier de conf monolithique de i3 étant un peu barbarre quand on multiplie les modes, j'ai aussi trouvé une astuce qui consiste à faire un script qui concatène des fichiers. Plus simple à maintenir et à répliquer les parties utiles d'une machine à l'autre (genre le mode audio et le lancement auto de ncmpcpp sur le netbook, il me sert pas: j'ai endommagé ce qui touche au son, alors je le réplique pas)
[^] # Re: Paquets disponibles pour Archlinux et Fedora
Posté par freem . En réponse au journal Steam sur Linux disponible au téléchargement. Évalué à -1.
Bon, c'est sûr, coller un truc dans /usr manuellement, c'est crade. Et en plus c'est ridicule… dans ce genre de cas, mieux vaut penser à /usr/local, ce me semble. Comme ça, y'a que les trucs installés avec make install qui sont mélangés.
Par contre, ton post montre une réflexion intense: je suis un newbie et ton post donne pas l'impression que tu en sois un. Alors sois /usr/local contiens des risques que j'ignore, sois tu n'as pas réfléchi avant de vouloir casser.
Accessoirement, je plussoie alien, et je plussoie aussi le fait que de toute façon, rpm n'est pas supporté par le kernel linux, d'autant que deb est au moins aussi vieux. La seule chose qui fait que rpm serait plus "linuxien" est une reconnaissance comme standard par lsb… sauf que je serai bien curieux de savoir pourquoi l'un plutôt que l'autre, d'autant que si j'en crois les sources que j'ai lues il y a quelques mois (j'ai plus les liens, mais ça se retrouve) deb serait en fait plus ancien (si on était vendredi, j'ajouterais qu'une raison potentielle du choix est le fait que rpm est contrôlé par une entreprise, mais je n'y crois pas trop moi-même)
Et j'ai aussi l'impression de voir plus souvent du debian-based que du fedora-based chez les nouvelles distros, alors au final deb semble plus proche du standard de fait…
Ah. Au fait, NVidia n'utilisais ni deb ni rpm la dernière fois que j'ai essayé ses drivers: seulement un run qui semble faire l'édition des liens… C'est p'tet plus celui la, le format standard de linux, non? Au mois, il marche sur toutes les distro ;)
[^] # Re: schtroumpf grognon
Posté par freem . En réponse à la dépêche De nouveaux jeux libres à découvrir. Évalué à 2.
Hum…
Personnellement, pour découvrir un jeu avec ma debian, j'utilise aptitude => vue par debtags et je vais dans la catégorie que j'ai envie.
Après, pour les catégories du menu "démarrer"… Aucune idée, j'en ai pas ^
Pour ce qui est du coup de gueule sur la packaging, j'ai envie de dire deux choses:
1) ".configure && make && make install" ça me semble dépassé, les dernières compilations que j'ai vues c'était "mkdir build && cd build && cmake .. && make && make install". Au moins la sortie est lisible et la procédure peut fonctionner sur n'importe quel OS.
2) avec cmake, il est possible de générer les paquets pour la plupart des distros en se prenant moins la tête. Moins, mais il faut quand même maintenir la liste des dépendances, et je me demande toujours pourquoi diable boost n'a pas de méta-package chez debian, chose qui oblige les dev à préciser le numéro de version dans le nom du paquet…
Pour le coup, la situation me semble meilleure (ou peut s'améliorer) grâce a cmake (je sais pas si les autres ont un mécanisme idoine aussi simple à gérer), mais il n'empêche que ça reste du boulot de maintenir le cmake pour chaque distro (combien, déjà? 400? de toute façon: trop pour maintenir). Et si le jeu n'utilise pas ce procédé sous prétexte qu'ils utilisent les PPA d'ubuntu, ben… à qui la faute?
Bien sûr, je parle de cmake, et peut-être existe-t-il d'autres mécanismes aussi chiadés (portable et simple), mais je ne les connais pas, alors je vais pas en parler ;)
Après, forcément, cmake n'est pas conforme à la philosophie POSIX, puisqu'il est capable de faire plusieurs choses, mais je ne veux pas lancer un débat sur le fait que ".configure" soit obsolète ou pas (bien que, personnellement, je pige pas comment ça marche, je me dis que d'autres ont peut-être le problème inverse)
[^] # Re: KDE en retard ?
Posté par freem . En réponse à la dépêche OpenBSD 5.2. Évalué à 5.
C'est surtout que quand on ajoute des fonctionnalités, on risque d'ajouter des bugs, tandis que l'usage d'une version un peu plus ancienne permet d'avoir eu plus de temps pour corriger ceux existants.
Je pense qu'il vaut donc mieux dire qu'ils pensent qu'il vaut mieux avoir un bug connu avec son contournement, plutôt que 2 bugs inconnus (et donc, sans contournement ou potentiellement dangereux pour la stabilité/l'intégrité du système).
[^] # Re: L'esprit du libre disparait...
Posté par freem . En réponse au journal Deux ans de projet libre : bilan. Évalué à 2.
Autant je comprend ceux qui t'on déconseillé, autant je ne suis pas d'accord avec les points abordés dans diverses réponses.
Je suis un contributeur jeune (je reprend depuis presque un an un projet* qui était mort depuis… 2006 je crois) mais ce genre d'outil existe, et fonctionne.
Sourceforge et savannah (qui ont la même base logicielle à l'origine) ont effectivement un outil pour que les gens d'un projet demandent des contributions. Et mon expérience actuelle montre qu'en moins de 2 semaines on peut se retrouver avec une 15aine de réponses. Certes, rien ne me dis qu'ils contribueront réellement, et même je doute avoir plus de 3 réels contributeurs dans cette masse, mais il me semble que le fonctionnement est réel.
D'un autre côté, ce projet, même s'il est mort (0 contrib depuis 6 ans) reste quand même à près de 600 dl/semaine. Je récupère donc une base d'utilisateurs non négligeable plutôt que de partir de rien du tout, ça doit aider à attirer (malgré une réécriture totale du code, pour rendre la bête utilisable en natif sur linux).
Autre point, ce logiciel était bien foutu côté simplicité d'utilisation (public visé: joueurs de jdr sur table/papier, pour créer des cartes et plans) et les dev ont donc eu une certaine reconnaissance. Parce que je sais pas pour vous, mais je pense que les logiciels de dessin simple à manier sous linux, à part xpaint (qui est mieux que mspaint mais quand même assez cru) ne sont pas légion.
En fait, même sous windows, on parle toujours de photoshop ou gimp… mais ce ne sont pas exactement des logiciels simples d'accès.
Du coup, le public visé est potentiellement large (tout en étant assez spécifique puisque centré sur les "rôlistes du papier" qui ne sont pas légion).
Après, il est évident que si on veut créer un logiciel, tant qu'aucune version exploitable n'existe, ça va être dur d'avoir des contributions.
Il est aussi évident que si le logiciel en question est YATEFD (Yet Another Text Editor For Developpers) ça va pas attirer: l'offre existante est déjà tellement conséquente.
Dans le cas qui t'intéresse, tu parles d'une fonctionnalité de forge logicielle. Ca implique:
_ public très restreint: techniciens seulement
_ nécessité d'intégration dans l'existant, pas évident vu le nombre de forge existantes
_ fonctionnalité déjà existante
_ nécessité d'auto hébergement, donc d'auto administration, alors que les contributeurs vont vouloir un truc qui permet de renter rapidement sur le projet auquel ils veulent contribuer
Sans vouloir être négatif, je doute effectivement que des gens soient attirés…
Quant au fait que "l'esprit du libre disparaisse"… Il m'a fallu 10 ans pour passer d'utilisateur à contributeur, et encore, je ne me sens pas capable de contribuer du code à ce que j'utilise quotidiennement: Codeblocks, linux, i3, lxterminal, vim, wxwidgets… trop complexe pour moi tout ça. (Il y avait bien flare qui m'intéressais, mais la politique de faire d'abord du code qui tombe en marche avant de refactorer ne m'a pas trop séduit).
Ce n'est pas surprenant qu'il y ait moins de contributions: avant, le libre était moins répandu, ceux qui le connaissaient savaient à quoi s'attendre et on édifié des logiciels impressionnants. Y contribuer du code rapidement n'est clairement pas à la portée de tous, et les petits projets, qui sont accessibles, sont les moins connus. Les gros projets séduisent parce qu'ils sont complets (y font même le café pour certains… et ce, même quand on aime pas le café) mais font peur aux contributeurs potentiels.
Mais pour autant, dire que l'esprit du libre disparaît… le public apprend l'existance de linux, pour certains, ils l'utilisent comme successeur aux logiciels fermés. On ne peut pas attendre de tout ces gens qu'ils contribuent. Il y aura toujours plus de sangsues que de gens pour aider, mais ça ne veut pas dire qu'il y a moins de contributeurs.
*: le projet en question sourceforge.net/projects/autorealm dès fois que ;)
[^] # Re: Merci !
Posté par freem . En réponse à la dépêche Entretien avec Martin Peres, développeur Nouveau. Évalué à 4.
"les cas où il fait bon l'utiliser. "
En hiver?
Perso, le pilote nouveau me va bien:
_ support de randr
_ pas de config Xorg à faire (en tout cas sous debian)
Seul "bémol" impossible d'utiliser 2 cartes branchées en même temps (cela dis, c'est précisé sur le site officiel) et il me semble que les jeux 3D soufrent d'une perf moindre, mais pas testé depuis longtemps avec NVidia et/ou windows.
Vu le peu de temps ou je joue à des jeux 3D, je préfère le confort d'un WM qui marche à celui de jeux qui carburent (en attendant les deux en simultané peut-être?).
Et puis tant qu'openMW arrive à fonctionner, donc ça me va.
En tout cas, merci bien à l'équipe de dev.