freem a écrit 5059 commentaires

Tout à fait, selon le paradigme que l'on utilise, une barre de titre peut être utile. Ou pas. En fonction, quoi.

Voila pourquoi, à mon avis, c'est le job du gestionnaire de fenêtre, mais je peux me tromper ( ce ne serait ni la 1ère ni la dernière fois ).

Sur un gestionnaire en stack, peut-être.
Sur un gestionnaire pavant, personnellement, j'en ai besoin, sinon je ne pourrais pas distinguer mes légions de terminaux les uns des autres…

Et puis je connais personne même sous Linux qui n'a pas sa fenêtre maximisée quand il surfe

L'intérêt d'avoir un navigateur non maximisé:
Divers usages possibles:
* lire de la doc,
* afficher des pages en corrélation avec la tâche courante
* déboguer un site web

Et ce, sans parler du fait que certains se servent de leur navigateur pour des usages différents ( via des plugin/applets: irc, musique, notamment )

Bon, ceci étant dit, avec un gestionnaire de fenêtre digne de ce nom, masquer la barre de titre d'une application est trivial.
Et probablement pas le job du browser.

Dans le cas de gimp, il n'y a pas de fondation pour financer des dev, tu l'as dis toi-même.

Mozilla et son produit phare, firefox, ne sont pas du tout dans la même catégorie, pour le coup. Et ça n'empêche pas gimp d'être manifestement un excellent logiciel ( je ne suis pas utilisateur, mais j'ai jeté un oeil ou deux dessus quelques temps. Si j'avais plus l'âme d'un graphiste, peut-être… ).

Sur gimp, la seule controverse dont j'ai eu connaissance, c'est le fait d'être multi-fenêtre. Bien que ça aie été corrigé, par défaut on reste dessus, et je trouve ça bien, ça rappelle aux gens que le logiciel est différent, et qu'il y a peut-être une raison derrière ( perso ça serait invivable avec un tiling wm, mais bon… ).

Mon opinion actuelle sur FF, c'est que:
1) il ne s'agit pas du seul bon browser libre ( c'est un fait, ça )
2) leur site ne respecte pas leurs idées ( GA, je l'ai appris ce funeste matin )
3) je ne me souviens pas de leur dernière innovation

Après, c'est sûr, je me contente au niveau implication dans le libre de patcher des trucs mineurs dans des logiciels mineurs en général, et d'aider sur la ML de debian quand j'ai le temps.
C'est sûr, c'est pas énorme, mais ça me paraît déjà moins pire que rien.

(ce qui est quand même un peu bizarre :p)

J'assume :)

on est obligé d'utiliser Opera 12.16 qui doit dater de fin 2012 …

Et je t'avoue que vue la gueule des derniers opera ( j'ai eu le malheur de devoir utiliser un windows il y a 3 mois ) je pense que je quitterai opera pour midori dans pas super longtemps, quand j'aurai réellement l'impression que mon browser est obsolète.

Mouai.

Désolé, mais question vie privée, moi, ils me font rire.

Et puis allez, même en admettant que leur navigateur respecte la vie privée des utilisateurs par défaut ( c'est à dire en admettant qu'ils ne proposent pas google par défaut pour tout ce qui à trait à la recherche, ou soyons gentils, en admettant qu'il n'y ait pas besoin d'aller dans about:config pour exterminer la bête… ), je trouve gonflé de dire qu'ils sont le navigateur à le faire le mieux.

Par exemple, midori, la dernière fois que je l'ai testé, n'utilisais pas google par défaut, mais duckduckgo. Qui est un moteur de recherche qui lui essaie de respecter la vie privée, contrairement à google qui ne se cache pas de vous espionner.
Alors en quoi FF respecte-t-il plus la vie privée que Midori? ( ce n'est qu'un exemple, personnellement j'utilise opera, mais comme personne n'a accès au code source on va me dire que rien n'est vérifiable si je le cite, et accessoirement c'est aussi google par défaut, même s'il est bien plus simple de l'éradiquer de la config )

Ceci dit, je ne savais pas que Mozilla ne respectait même pas le DNT… Ça, c'est très fort. Avant, je n'appréciais plus leur navigateur pour des raisons diverses, mais aucune liée à la vie privée. Ça viens de changer.
Dommage, j'aime quand même bien le fait qu'ils essaient de garder un moteur de rendu différent, eux. ( c'est le seul truc qui les sauve encore à mes yeux du coup )

Sinon, je connais un projet bien plus gros et qui ne me semble être cohérent avec ses idées: Debian. Si eux y arrivent, pourquoi pas Mozilla?
Alors que Debian à été crée from scratch en libre, contrairement aux produits de Mozilla, d'ailleurs ( qui ne sont donc pas partis de 0, ça devrait être plus simple ). Mozilla, leur seul but réel, c'est d'avoir la plus grosse… c'est comme ça que je le perçois en tout cas. Et pour ça, on copie simplement la concurrence ( système de version, ihm… y'a que le moteur de rendu qui est unique! )

PS: heureusement qu'il y a linuxfr pour me consoler de ce vendredi de pont passé au bureau \o/

J'attends les arguments contre le format de paquet RPM :).

Et moi ceux contre les deb? Pour le moment, dans ce journal et ses commentaires, il n'y en a eu aucun.

Il y en a ici.

Pour être plus précis ( attention, je parle bien d'argument contre l'install sur un serveur de production, nous sommes d'accord! ):

Fedora has a reputation for focusing on innovation, integrating new technologies early

Intègre vite. Donc, peu de test, donc de bugfixes.

Fedora has a relatively short life cycle: version X is supported only until 1 month after version X+2 and with approximately 6 months between versions this means that a version of Fedora is supported for approximately 13 months.[7] This promotes leading-edge software because it frees developers from some backward compatibility restraints, but it also makes Fedora a poor choice for product development, which usually requires long-term vendor-support.

Ici, c'est expliqué pourquoi en prod c'est moyen… je vais pas paraphraser.

The default desktop in Fedora is the GNOME desktop environment and the default interface is the GNOME Shell.

Donc, par défaut, une interface graphique est installée? Pour un serveur? ( je sais, la plupart des distros aussi l'installent par défaut, et j'imagine que ça se désactive lors de l'install, mais je me mets au niveau de ton journal en restant sur le par défaut. )
Vu que tu sembles ne pas aimer l'automatisme sur les serveurs ( après tout, un service installé ne devrait pas être automatiquement démarré, pas vrai? Après ton install de fedora, le serveur graphique fraîchement installé est bien démarré, pas vrai? ) tu ne dois pas trop aimer ça.

Fedora uses the RPM package management system.

Ah… moi, je préfère celui de Debian, donc celui Debian est mieux et celui de fedora/RHL mauvais. Je suis encore une fois à ton niveau quand tu dis "Debian, si on aime bien sa gestion de paquets".

Basiquement, on m'a toujours parlé de Fedora comme d'une excellente distribution, à destination des dev et des early adopters.
Donc, je ne pense pas qu'elle soit mauvaise, et avec une boîte comme RHL derrière, j'aurai tendance à avoir confiance dans la bête.
Mais pas pour un serveur, sur lequel il est plus pertinent d'utiliser RHL elle-même ou Debian. En mode minimaliste. ( D'ailleurs, je n'ai pas apprécié quand Debian ont activé l'installation par défaut des paquets recommandés… par chance, ça se désactive, mais obligé de tout décocher à l'install de base, c'est dommage. )

Changement de distribution dans les sources ;
apt-get update ;
apt-get install screen ;
dans screen :
apt-get dist-upgrade ;
apt-get --purge autoremove $(deborphan) (relancer autant de fois que nécessaire) ;
reboot.

Quel est l'intérêt de screen? je veux dire, à part avoir un tiling window manager pour gérer le contenu d'un terminal…
Au passage, je me suis toujours demandé à quoi exactement sert deborphan. J'ai dû l'installer une fois ou deux, mais il n'a jamais été capable de virer le moindre paquet automatiquement. D'ailleurs, je n'ai toujours eu besoin au maximum que de 2 passes dans aptitude pour virer complètement un logiciel. ( ça m'arrive moins maintenant, mais à l'époque ou je cherchais encore mes marques j'ai pu aller jusqu'a installer/supprimer une 30aines de logiciels divers par semaine… histoire de tester. )

En tout cas chezmoicamarche™.

C'est sûr, après, tout dépend des logiciels que tu utilises. Certains sont plus ou moins bien maintenus, et si on tombe plus dans le moins que dans le plus, un ou deux peuvent péter.

Du coup, ça impliquerait que les russes soient meilleurs que la moyenne pour les langues, puisqu'ils exploitent dès l'enfance toute la gamme de la voix humaine?

Dans la même "raison", est-ce que quelqu'un pourrais me dire en quoi le fait de mettre à jour un service sans le redémarrer aussitôt est gênant?

Déjà, pour un poste de bureau, ça ne pose aucun souci, c'est rapide et n'interrompt potentiellement l'utilisateur qu'a peine une dizaine de secondes ( je suis large, très large, parce que mon expérience sur une machine desktop mise à jour régulièrement montre plutôt des "interruptions" d'a peine 2s. C'est surtout "gênant" pour mpd… le reste… bof. ).

Et pour un serveur, rien, strictement rien, n'empêche de faire la mise à jour du service uniquement au moment ou l'on veut le redémarrer. Avec un cron job, par exemple.
Et accessoirement, ça me semble éviter les situations ou un daemon est à jour sur le disque dur, mais l'admin ayant oublié de le redémarrer, il a conservé les failles dans la RAM…

Me trompe-je?

Fossil pourrais faire ton bonheur… sauf sur un point en fait: il n'a pas besoin d'apache pour offrir une IHM web.

Mon opinion à ce sujet est qu'en fait ce n'est pas plus mal, mais je t'avoue ne pas l'avoir encore réellement utilisé, surtout parce que je n'ai encore jamais cherché à déployer une forge complète par moi-même.

Ah, et pour l'intégration continue, je ne suis pas sûr non plus. Je sais qu'avec git il est très simple de mettre des trigger sur les commandes ( par exemple pour lancer des tests unitaires ou mettre un coup d'astyle automatiquement ) mais c'est un truc que j'ai découvert récemment, alors que je "connais" ( de nom ) fossil depuis l'époque ou je me suis penché sur les DVCS, c'est à dire à peu près 4 ans.

Niveau difficulté d'installation, il s'agit d'un seul binaire ( même pas 1.5MiO de mémoire, porté sous windows ), les données étant contenues dans une DB sqlite3. Il inclue aussi un wiki, chose que tu ne demande pas mais dépanne parfois, bien que ça ne remplace pas un site web réel.

Pour avoir essayé d'installer redmine au taf, je pense que sur un projet perso, je partirais plutôt sur fossil, parce que bon, d'être obligé de galérer comme un mort, ou d'installer à partir des sources ( et donc pas via apt ) m'ennuie à l'extrême. Sans parler des tonnes de dépendances: ruby, un sgbdr, un serveur http… ça pèse lourd quand même l'air de rien, sans compter que quand tu es hors ligne ( train, avion, étranger, que sais-je ) tu n'as plus accès aux tickets, contrairement à fossil, justement.

En espérant que ça aide…

C'est à dire?
L'écran conserve sa luminosité, alors que tu as appuyé sur les touches?
Si c'est le cas, as-tu vérifié qu'il y a une action déclenchée par l'appui sur les touches en questions?
A priori, sur mon netbook, c'est géré naturellement… c'est à dire que je ne sais pas du tout qui s'en charge. Probablement ACPI.

En revanche, sur mes desktop, il m'arrive de le faire aussi. Là, bien entendu, il n'y a aucune touche clavier dédiée, donc j'ai du binder à une combo de touche l'option xrandr pour modifier la luminosité: brightness, si je ne m'abuse.

Si tu sais comment marche l'ACPI sous linux, tu as le droit de m'indiquer ou trouver des docs faciles à comprendre pour les bases, sinon, tu peux peut-être jouer avec cette option de xrandr.
Dans tous les cas, je suis surpris que systemd interfère avec ACPI…

Ajouterais-tu de l'eau au moulin de ceux qui disent qu'a force de trop en faire, il ne fait rien correctement ? hinhinhin

Hum…
Le 1er lien, non.

GtkAda, j'en ai entendu parler ( enfin… lu écrire ), mais… j'avoue, utiliser un binding ADA d'une lib C ( alors qu'ADA supporte l'objet, et pas le C ) me semble…hum… pas pertinent.
Je voulais troller en disant que j'aurai préféré un binding qt, mais après une rapide recherche, j'en ai trouvé un… hé zut bon sang…

Pour la SDL, j'avais cherché, mais n'était pas tombé sur ce lien.

Conclusion: je vais éplucher tes liens plus en détail. Les recherches que j'ai faites sur le canard ne me les avaient pas pointées, si je ne me trompe pas.

Comme sanction, je te pertinente un dredi, ça t'apprendra, na!

Le problème, c'est que cups ne gère pas que les imprimantes réseau.
Et que la majorité des utilisateurs n'ont pas d'imprimante réseau: la majorité des utilisateurs de PC ( pas de linux, ceci dit, j'imagine ) ne sont pas des entreprises, mais des particuliers. Donc, pas d'imprimantes réseau, si je ne m'abuse.

Si c'est un problème de visualisation, genre, luminosité trop faible/forte, xrandr pourrait vous aider.
Ca n'est qu'une bidouille logicielle par contre donc pas sûr qu'une économie de batterie soit espérable. Enfin, faut voir la nature exacte du problème après j'imagine.

En fait, tu souhaiterais qu'ils mettent la fonction en deprecated avant de la virer quoi?

Tu te rends compte de la somme de travail et maintenance que ça leur demanderais?
Je ne parle pas au niveau du code, bien entendu, mais au niveau moral: il leur faudrait alors accepter que ce qui est nouveau n'est pas optimal!

Non, testing n'est pas censé recevoir les dernières nouveautés. Testing, c'est la beta, après tout.

Au fait, quelqu'un sait comment sont incrémentés ces numéros de version?
Je n'arrive pas à les lire…. enfin… à les interpréter.
Avec le système initié par ubuntu, donc, les dates, on arrive à connaître l'âge d'une version.
Avec le système plus éprouvé M.m.b on arrive à estimer la différence de fonctionnalités.
Mais, avec les numéros débiles type firefox, chrome, et systemd, je n'arrive vraiment pas à avoir la moindre idée de la somme des changements entre 2 versions…

Pour les archis restée en 44, c'est pas illogique qu'elles ne soient pas montées plus haut. Ces systèmes sont minoritaires, et la portabilité de systemd est plus que discutable. Le sieur Lennart code pour la dernier version de linux, si je ne m'abuse, et les autres peuvent aller brouter ailleurs.
Conclusion: ceux qui ont des archis différentes, auront des emmerdes avec systemd. Mais bon, rien de neuf ici.

Rien de visible sans JS? A part un avertissement que sans JS c'est pas optimal… ( en meme temps, y'a rien, sans JS :/ )

Après activation, rien non plus ne s'affiche.
J'utilise opera en JS désactivé par défaut, je l'ai activé pour le site, mais… plus rien du tout.

Pour certains usages, je peux comprendre, mais pour une FAQ? Ce n'est pas censé être juste une page avec:

• un sommaire
• une liste contenant:
  • n questions
  • une réponse associée à chaque question

Et donc, pourquoi nécessiter JS pour si peu? Je sais, je suis chiant de désactiver JS par défaut. Mais c'est pour la sécurité de mon système, qui n'est en plus pas super musclé et donc, sur certains sites ( pas rares ) , JS pourrit l'utilisabilité de la machine.

J'imagine que tu plaisantes, mais j'ai récemment songé sérieusement à me mettre à l'ADA, qui offre un certain nombre de points commun avec le C++, en mieux ( encore plus casse-pied sur les types, il paraît… J'aime bien l'idée! Et puis, un langage qui produit de vrais binaires, vraiment lisibles par le CPU, ça se fait rare de nos jours, alors en connaître 2 ( 4 si je compte le C et l'asm intel x86 - hum, et encore - … ) me ferait bien plaisir )

Par contre, il semble qu'il y ait un manque critique de lib pour gérer correctement les IHM sous ce langage. Il y a aussi le fait que gnat soit infernal à utiliser. Ce truc est le pire IDE que j'aie tenté d'utiliser sérieusement… GUI bordélique à souhait, on sait même pas ou aller pour compiler un nouveau projet. Bref. Je ne parlerait pas du tuto qui présuppose un nombre élevé de trucs. Ca reste de la doc de gnou, dans le genre bestial on fait difficilement mieux (avis personnel).
Et je n'ai pas trouvé grand chose (rien en fait, mais j'avoue que pour m'initier à un nouveau langage, j'aurait préféré un outil qui en fasse un maximum à ma place, pour commencer gentiment. Donc pas plus cherché que ça) au sujet de compiler en ligne de commande, non plus ( pourtant, ça me suffit amplement, compte tenu du fait que mon système utilisateur est un vrai IDE pour c++ en tant que tel, à condition de savoir taper 3-4 commandes ).
SDL à un portage entamé pour ADA( sur github ), par quelqu'un qui veut prouver qu'on peut faire des jeux en ADA ( ce qui, compte tenu du fait que ce langage soit conçu pour créer des armes militaires, et donc pour être hyper fiable tout en pouvant gérer du bas niveau - comme C++ en fait, sauf pour les armes militaires - , me semble pas stupide! ). Mais je crains que ce portage ne soit pas spécialement utilisable.
Le concurrent de la SDL, la SFML, ne supporte certainement pas l'ADA, et personne ne semble s'y être mis ( logique, SFML est déjà peu utilisée en C++, alors porter pour ADA… ).
Et pour finir, il semble que, comme C++, ADA n'ait pas de lib pour créer des GUI, ou plutôt pas de "lib mainstream" ( mais pour un langage si peu connu… pas surprenant ).

Pour un jeu vidéo… ces détails sont gênants, car le jeu vidéo fait une grande utilisation de l'écran, et pas juste pour afficher 3 caractères qui se battent en duel ( toujours, toujours compter le témoin! Sinon, c'est un assassinat ;) ).
Du coup, coder un jeu en ADA serait… particulièrement intéressant, pour moi. Réinventer la roue n'est pas systématiquement mauvais ( la plupart des libs de toolkit le font, après tout, sauf wx ) si l'on fait un truc propre qui n'est pas lié par les contrainte historiques du langage.
Mais je ne crois pas que tout le monde serait d'accord avec moi. Réinventer la roue, remettre en question les implémentations séculaires ( ou demi-séculaires pour les logiciels ) n'est pas toujours bien vu, surtout s'il existe un truc libre.
Il s'agit de quelque chose que j'aimerais bien faire, en fait. Faire différemment des autres, par esprit de contradiction, mais aussi parce que je serais toujours moins bon que les autres dans leur domaine d'expertise si je me contente de les singer. Et faire différemment permets parfois de trouver de nouvelles façons efficaces de faire les choses. Les inventions et trouvailles majeures liées à des erreurs, ça existe, après tout (on peut rêver).

PS: si t'as des document expliquant comment faire un vrai hello world, en ligne de commande, pas à pas, expliquant la syntaxe et les paradigmes du langage plutôt que des trucs aussi inutiles que la description de l'API des fonctions standard ( pour lesquelles un lien vers un document les expliquant de façon technique me suffit. Je ne suis peut-être pas un maître du dev, mais je suis un dev malgré tout, lire de la doc d'API me fait pas peur. )
A partir d'un truc aussi petit, qui explique comment compiler et la syntaxe, on peut apprendre très vite le reste. Créer un mécanisme de GUI n'est pas si dur après tout: une classe fenetre, une sizer qui en hérite et agrège une liste de fenetre, une spacer qui hérite de fenetre, et une widget qui hérite de fenetre et agrège une image, et la moitié est faite. L'autre moitié, c'est dire que fenetre agrege des gestionnaires d'évènements… rien d'extraordinaire. Et avec la prog générique, on peut faire un truc qui aie le même comportement en mode graphique ou en mode texte en plus.)

PPS: pardon pour le pavé

La solution:
Utiliser GNU/FreeBSD :p ( faut vraiment que je fasse le test, d'ailleurs )

C'est normal.
Après tout, Debian vise la stabilité, et, même s'ils ont accepté de passer à systemd, ils ne vont pas mettre à jour la stable à chaque version de build, qui apporte manifestement autant de bugfix que de nouveaux bugs nouvelles fonctionnalités.

( vous m'avez pourri mon dredi à pas troller pendant mes 7H… alors je me dévoue un peu )

Et pas de commentaire sur les trucs intéressants pour l'utilisateur final

En même temps, systemd, c'est pas censé être une amélioration pour l'utisateur final… ( le vendredi, c'est permis, non? )

Plus "sérieusement", j'ai réussi à me forcer à lire tout… jusqu'a la fin de la 1ère version ( par ordre d'apparition dans le nourjal). Après… TL;DR.
Alors, c'est vrai qu'un bon troll de compèt n'a pas besoin de lire, mais tout le monde ne peux pas être expert.

Merci de ton retour (quand je repasserais dans une période de gamer, je tenterais sûrement).

J'avoue ne pas être surpris, au vu des avis relativement unanimes que j'en ais lus sur le ouaib, mais, je me suis toujours demandé ( et flemme de chercher/expérimenter moi-même ) comment ça marche au niveau installation/configuration?
A part l'habituel "./configure && make && make install" je veux dire.

Est-ce complexe? Parce que j'avoue: autant j'aime me prendre la tête pour coder voire configurer mon environnement de bureau… autant, pour un jeu, non, ça ne me tente pas, et je me laisse aller à la faiblesse de rebooter en mode windows XP.
Ce qui est dommage, parce qu'a chaque fois que je le fais, je me sens juste… un peu comme un randonneur qui se récupère des béquilles… ( le gestionnaire de fenêtre de windows, quand on est habitué à i3—donc du tiling—est vraiment douloureux! )

Pour communiquer avec des appareils sur la distance, je crois que d'habitude on utilise des câbles ethernet. Après, rien ne t'empêche de les utiliser pour autre chose que le protocole tcp/ip. Ni de faire un adaptateur usb/rj45 pour ne pas avoir à modifier le câble ou l'arduino.