Allez, juste une précision (foutu timing à la con) sur le gestionnaire de tickets. Parce que, en fait, je te chambrais pas tant que ça, c'est réellement simple à gérer pour faire un truc trivial.
Via xclip. Et ton gestionnaire de fenêtre. Et Xorg.
Tu ne tilte pas?
Avec Xorg, quand tu sélectionnes un texte, il est automatiquement copié dans un presse-papier spécial. Tu colles un binding dans ton gestionnaire de fenêtre, qui utilise xclip pour ajouter le contenu du presse papier du bouton central à la fin d'un fichier HTML, qui n'est pas fini proprement (pas de </BODY></HTML> donc). Les brouteurs sont assez malins pour s'en sortir de nos jours. T'en fais pas pour eux.
Bref, tu as plus qu'à mettre ce fichier en page par défaut ou en signet dans tous tes navigateurs, et le tour est joué. Si tu veux centraliser, tu peux scriptouiller avec ssh pour synchro ce fichier, mais je suis parti pour faire un truc vraiment trivial, la on «complexifie».
Pas super clean, de la bidouille, certes. Mais, sans cahier des charges plus précis que ce que tu as donné, ça semble correspondre à ton besoin. Et me mets pas au défi de faire une arborescence, t'as un super logiciel nommé système de fichier qui sers à faire ce genre de trucs sur ta machine. Hé oui, les fichiers et les dossiers, ça fait des arbres. Donc, y'a moyen de faire un truc plus chiadé, en y passant moins de 4H, qui soit compatible avec tous les brouteurs compatibles Xorg.
Faut juste que celui qui en a besoin se sorte les doigts.
Pas moi. Je n'utilise quasiment pas linux, ou plutôt, je ne l'utilise pas de manière consciente. J'utilise Debian, ouai. Linux, uniquement parce qu'il se trouve que c'est le kernel que Debian utilise. Ça pourrait être un BSD, que ça me poserais pas plus de soucis que ça. Ce que j'aime, au fond, c'est les émulateurs de terminal 1000 fois supérieurs à celui de windows, l'interpréteur de commande bash qui est tellement puissant qu'il relègue la souris dans la zone du bureau ou réside la chope à bière, aptitude qui me permets de maintenir mon système au jour le jour sans installer 3 milliards de merdes et sans jamais rien casser… du moins, jamais sans me prévenir que ça va péter.
Rien à voir avec le kernel, vraiment.
N'empêche que depuis tout ce temps, j'aimerais bien que mon bureau linux me permette enfin d'accéder à l'agenda lorsque je clique (ou clic droit) sur un jour, de manière à y inscrire directement un rendez-vous,
Tiens, je pensais que ça existait ce genre de jouets. Les trucs style calendar le font pas? Ils sont donc encore plus inutiles que je ne le pensais, c'est triste.
ou qu'il soit enou qu'il soit enfin possible d'avoir un vrai NetLimiter en espace utilisateur (trickle est à des années lumière d'un NetLimiter)
C'est clair, ça serait pas mal.
Le problème, c'est que pour ça, il faudrait… hem… faire un truc extrêmement difficile pour un éco-système dont la force vient de la diversité: standardiser. Uniformiser. Pour créer une API acceptée par tous les développeurs, y compris les NIH (dont je fait partie, je le sais et je n'en ai pas honte) qui codent pour le fun (voila pourquoi j'en ai pas honte) des applications que d'autres sont libres d'utiliser ou pas.
En fait, il faudrait un PulseAudio pour le réseau. Sauf que le réseau, il est bien plus complexe à gérer que le son, puisqu'il dépend pas mal de l'extérieur. Pour ne pas dire complètement. Et PA semble avoir causé pas mal de remous comme ça… de remous et de casse si j'en crois mes lectures (mais on ne lis que ceux qui ont eu des problèmes, donc…).
régler dynamiquement les limites de bande passante de chaque téléchargement/accès réseau individuellement
Pour finir d'enfoncer des portes ouvertes… c'est au navigateur de savoir gérer sa bande passante correctement. Je doute que tu utilises 20 000 logiciels pour squatter ton réseau, pas vrai? En gros, je vois 2 types de logiciels qui exploitent régulièrement le réseau sur une machine personnelle: le brouteur, et un gestionnaire de téléchargement. Très sincèrement, c'est clair: si seulement les brouteurs intégraient un gestionnaire de téléchargement digne de ce nom, ça serait tellement plus confortable. Bon, ça réglèrai pas le problème d'apt qui squatte toute la bp quand on lance une maj, mais… ça serait déjà pas mal. Mais, pas la faute à Linux, ni même aux distros ça: ils préfèrent se concentrer sur le tape-à-l'œil, le chteumeuleu 5, pour faire plaisir à ceux qui ne savent pas trop ce dont il s'agit et ne peuvent s'empêcher de cliquer là ou ça gigote.
avoir ses foutus signets partagés localement entre tous les navigateurs de manière standardisée sans avoir à faire des imports/exports ou synchronisations et sans dépendre d'un service en ligne,
Hum… Si je ne m'abuse, il est trivial d'ajouter à un fichier (echo foo >> my_file) une ligne contenant un lien. Bon, ok, je chambre un poil. Certes. Mais, ce problème n'est lié ni à linux, ni à windows, ni à quelque démon obscur. Juste au fait que les navigateurs se font la guerre.
Et personne n'oserai repprocher à mozilla ou chromium de ne pas être compatibles entre eux pour leurs données internes, pas vrai?
ou encore qu'un grand ménage soit enfin fait dans le bordel des fichiers de configuration et de données des applications dans le home/
Ah, mais, c'est ta faute ça. Pourquoi n'utilises-tu donc pas que des applications qui suivent FreeDesktopOrg? Beaucoup le font. Il ne doit pas en rester tant que ça qui ne le font pas, excepté les trucs de barbus genre vim, bash & co. Et je doute fort que les patcher soit si difficile pour changer une localisation de fichier de config, si vraiment tu ne peux te passer de ces outils (comme moi) et que ça te gêne tant que ça (pas comme moi).
Enfin bon, si je comprend bien, tu aimerais que ton bureau, te répondes au doigt et à l'œil? Et ce, sans avoir à le customiser au p'tits oignons toi-même?
Je meurs d'envie de répondre qu'il y à déjà les outils pour faire ce dont tu rêves, mais que la seule chose qui fait que ce n'est pas encore fini, c'est que ça manque de volontaire… mais on m'accuserai de te provoquer j'imagine.
Perso, j'ai trouvé une solution très acceptable: j'ai fabriqué mon DE à partir de pièces détachées trouvées dans aptitude. Ça marche super bien, c'est hyper léger, hyper réactif, je contrôle tout du bout des doigts sans bouger les poignets, c'est… le pied, si j'ose dire :)
Bref, sors-toi les doigts, la solution la plus adaptée à tes besoins existe déjà, il faut juste que tu mettes les pièces ensemble. Si tu as la flemme, très bien, mais assumes ton choix de ne pas investir ton temps pour en perdre moins par la suite. Et si d'aventure je me trompais, si tous les logiciels dont tu as besoin n'existent pas, je t'encourage à les créer, que ce soit pas toi-même, ou en les faisant faire, d'une manière ou d'une (oui, ça peut vouloir dire embaucher des gens, mais, après tout, c'est pour ton confort personnel), par les autres.
Que tu aies découvert les joies de la programmation avec l'assembleur, très bien.
Ben, non en fait.
mais moi j'ai commencé par le BASIC
Tiens, moi aussi. Et justement, c'est là que j'ai commencé à bidouiller la mémoire et le mode 13H en fait. DEF SEG = A000: POKE foobar, 255ou un truc du genre pour allumer le pixel foobar en blanc, non? On pouvait aussi appeler du code C ou ASM de cette façon si ma mémoire ne m'abuse.
Pour moi tous les professionnels de la programmation doivent avoir fait pendant leur cursus de la programmation en langage assembleur
Je ne serai donc jamais un pro. Tant pis :) Pas sûr de le regretter, de n'être pas considéré comme pro, à bien y réfléchir.
Malheureusement, je n'ai fait de l'assembleur que parce que je suis auto-didacte, le discours quand j'étais à l'école (ça remonte maintenant, pas loin de 10 ans, déjà :/) c'était plutôt: «laisser le client racheter du matos, collez donc des int pour stocker des char». J'étais en BTS IRIS, le successeur du BTS info indus selon les profs. Ça m'à écœuré du code pendant plus d'un an après ma sortie des études leurs discours. Et le fait que 80% des TPs consistaient à manipuer l'IHM de VS pour dessiner des fenêtres…. beurk! Ça doit expliquer en partie mon aversion actuelle pour les IHMs j'imagine.
la plupart des programmeurs ont choisi ce domaine parce qu'ils pensent qu'ils pourront trouver du boulot .
Mon opinion sur ce sujet est trop embrouillée pour être exprimée sur un forum.
Modifier le boot de ton PC installeur pour qu'il démarre sur une iso d'installation. C'est le plus simple, et c'est d'ailleurs ce que je fait sur un de mes disques durs externes: multi boot, install de debian 32, 64 bits, install de netbsd (que j'ai pas encore utilisé d'ailleurs), boot sur debian 32 ou 64 bits. Choix au démarrage, comme il se doit. Configuré via Lilo, avec grub j'ai trouvé la doc bien trop bordélique.
Un p'tit disque dur bootable presque partout quoi :)
Il te faut identifier le nom du paquet contenant le logiciel que tu veux, et l'installer via ton gestionnaire de paquets.
Dans le cas de mint, c'est basé sur Debian, donc, moi, ce que je ferai, c'est que je lancerai aptitude (via un terminal), pour chercher (touche '/') les paquets installés contenant les mots qui m'intéressent sur la machine qui l'utilise. Tu peux aussi utiliser l'arborescence, c'est plus long mais ça sera peut-être plus simple pour quelqu'un qui n'est pas habitué.
Je ne suis sûr d'avoir tout compris, ton message n'est pas très clair à ce sujet.
Avec le DE mate, sous Debian Jessie tu as le problème.
Idem avec XFCE, même système.
Avec le pilote proprio, ça marche mais plus au bout d'un certain nombre de redémarrage.
Avec le DE gnome, sous Debian Squeeze (l'ancienne old-stable, quand même) et pilote propriétaire c'est stable?
Dans ce cas, je dirais, problème d'accélération graphique, essaie de la désactiver. Ou de vérifier que tes pilotes sont à jour.
Si j'ai mal compris, j'imagine qu'il va falloir reformuler :)
Dans le bon sens du terme? Vraiment? Je ne suis pas convaincu, le fun ne dépend pas de la complexité. D'ailleurs, à l'heure actuelle, la plupart de la complexité se situe au niveau du GPU pour le coup, à grands coups de maths. Erk.
Après, au niveau des programmes eux-mêmes, je les trouve régulièrement inutilement complexes. Il y à d'ailleurs un certain nombre de personnes en prog qui favorisent le principe du Keep It Simple and Stupid. Ce n'est pas pour rien.
seule la nostalgie peut vous permettre d'en garder de bons souvenirs.
Non, l'époque (pas si lointaine, un peu plus d'une décennie) ou je tapais mes premières lignes de code et apprenais à désassembler des binaires ne m'évoque pas de bons souvenirs que pour la nostalgie, mais aussi parce que, bon sang, c'était tellement plus simple à l'époque de faire des trucs simples en programmation!
À l'heure actuelle, pour réussir à allumer 1 pixel, il faut se taper une bibliothèque… non, pire en fait, un framework complet… À l'époque ou l'accès au matos était direct, il suffisait de quelques lignes d'assembleur, de l'ordre de quelques 10aine (une interruption pour changer le mode graphique, genre le 0x13, puis balancer les données direct dans A000:0000. Si mes souvenirs sont bons.).
Pas sûr que je serai toujours barré dans le code si je n'avais commencé avec une technologie certes obsolète à l'époque (ben oui, le mode réel en 2002-2003, c'était un poil obsolète) mais assez simple pour être comprise par le plus grand débutant. J'ai commencé l'informatique tard, et je n'avais rien d'un informaticien à ce moment là, j'étais plus un rat de bibliothèque…
Quand je vois le mal que mes profs d'info ont eu (2006-2007) à expliquer aux autres ce qu'était un pointeur ensuite, alors que la plupart des gens venaient de STI électronique, je me demande si commencer par du matos et des techniques obsolètes mais simples n'a pas un certain intérêt.
Penses à la nature et au porte-feuille: pourquoi graver des .iso, quand on peut booster une iso à partir d'une clé USB? En plus, ça sera probablement plus rapide qu'un lecteur DVD.
Et tu auras plus facilement de l'aide sur ubuntu, il y a un forum et un wiki francophone très bien d'ailleurs et qui aide beaucoup les débutants.
Ma foi, il arrive souvent que pour les questions les plus simples, la réponse soit presque la même pour toutes les distributions. Debian, Ubuntu, ou autre, peu importe si la question concerne une application avec interface graphique j'ai l'impression.
ElementaryOS étant une "modification" d'ubuntu, j'imagine que les astuces pour ubuntu fonctionnent globablement sans soucis sur elementaryOS.
Probablement. De la même façon que ce qui marche pour Debian marche pour Ubuntu. Peu importe la distribution, l'important c'est plus l'environnement graphique (pour un débutant du moins) que ce qu'il y à sous le capot.
En tout cas, si tu as réussi à le lancer en TTY, je suis preneur de la procédure (suis sous Debian old-stable moi. Pas trop sûr de vouloir passer à Jessie, de toute façon ça n'urge pas). Ce navigateur m'intéresse, et pas juste pour ça: le fait que le moteur de rendu ne soit pas un des grands classiques et qu'ils visent la légèreté m'intéresse très fortement.
Comment ai-je pu ne pas penser à un truc aussi évident… Merci! Plus qu'a filer à bash les arguments pour spécifier quels fichiers de conf lire, et c'est nickel (trivial, bash à au moins un man clair).
Tu devrais regarder BSD Owl et sa fonction subshell:
Intéressant, j'y jetterai un œil, même si j'ai un mauvais apriori des Makefile. Ça pourra me filer des idées ou même me convaincre que finalement, «les Makefile,c'est trivial». Pointe d'humour, mais si je n'aime pas les makefile, c'est surtout que je les trouve illisibles. Sans parler du fait qu'il y ait une différence syntaxique entre les divers caractères blancs, c'est typiquement le genre de trucs qui me fait tiquer. Et la raison principale pour laquelle me suis pas encore essayé au python.
la version BSD, pas GNU.
Je ne savais pas qu'il y avait tant de différences que ça.
Pour prendre un projet complexe en C le fichier Makefile principal ressemble à:
Le pire, c'est que tu vas me convaincre… c'est bon ça! concis! lisible! maintenable (à première vue du moins)!! Bon, demain férié, rien à faire à part zoner sur le net ou coder, bah je pense que je vais tester. Sûrement tester ce soir aussi, pour le coup (je devrais être capable d'installer/tester netBSD sur une autre machine en même temps, ce que j'avais prévu comme programme pour la soirée héhé).
Le problème, c'est que ça ne supprime pas les variables. Le shell enfant hérite des variables de son parent, ces deux options permettent simplement de sauter les fichiers de configuration.
Petit complément sur la compatibilité des licences:
La licence MIT est compatible avec la licence GPL parce qu'elle est moins contraignante, la GPL pouvant avoir des incompatibilité avec d'autres licences à cause de sa viralité.
Dans le cas d'un logiciel qui serait écrit sous une licence MIT mais utiliserais une licence GPL, il serait obligatoire de distribuer le source du logiciel (aux utilisateurs du dit logiciel, pas au monde entier! Ces utilisateurs en revanche auraient le droit d'en faire ce qu'ils veulent, notamment refiler le code au monde entier…), malgré sa licence MIT, à cause de cette viralité. Le seul intérêt de faire cela serait donc le fait qu'il serait possible de stopper la diffusion du code une fois la dépendance à la GPL supprimée.
L'inverse, c'est à dire utiliser une licence MIT dans un projet GPL, reviens au même, sauf que l'on est pas obligé de distribuer le code de la bibliothèque.
Enfin, dans le cas de la LGPL, distribuer le source du logiciel n'est obligatoire, de mémoire, que si l'édition des liens s'est faite de manière statique, c'est à dire que la bibliothèque et le programme ne représentent qu'un seul binaire. Dans le cas de l'édition dynamique (DLL pour windows, so pour linux), cette contrainte disparaît.
Bon, c'est assez brut comme explication, pas hyper précis, encore moins exhaustif, et je me trompe peut-être même sur certains points. Je ne suis pas légiste, et sincèrement, la GPL me semble s'être encore compliquée avec sa version 3… maintenant je préfère utiliser des licences type BSD, au moins ça tiens en même pas 10 lignes, c'est clair, et pas prise de tête à gérer. Pas comme si mes bouts de code étaient difficile à reproduire, voire refaire en mieux de toute façon :D
Ce n'est pas firefox, il manque encore un bon support de JS (de mémoire, faudrait que je reteste), mais tu seras peut-être intéressé par netsurf.
Sous Debian, j'ai 2 paquets principaux: netsurf-fb pour le framebuffer, et netsurf-gtk.
Par contre, j'avoue n'avoir jamais testé la moindre application graphique sous une TTY, et la, un rapide test tant avec mplayer qu'avec netsurf me fait penser qu'il y à de la config à faire, ou je ne sais quoi.
Faudra que je m'y mette un jour, ça peut servir.
Il y à eu plusieurs discussions sur la ML Debian également sur le sujet de la sécurité. Testing était également considérée comme la pire version de ce point de vue. Ceci dit, il me semble que depuis un dépôt security à été créé pour testing.
Super merci!
Je vais pouvoir enfin essayer de jouer avec valgrind du coup (reste à apprendre à s'en servir correctement, mais j'imagine que ça viendra avec la pratique ça).
1) ajouter le dépôt de Jessie, aka testing, pour installer les lib manquantes. Le problème, c'est qu'il te faudra très probablement mettre à jour certains paquets qui forment le coeur du système. Et si tu veux éviter de mettre à jour le système entier, il te faudra jouer avec le fichier /etc/apt/preferences (ou ajouter un fichier du même type dans /etc/apt/preferences.d, au choix) ce qui n'est pas vraiment trivial.
2) compiler les libs libavcodec54 (ou libavcodec-extra-54, au choix), libavformat54, libavresample1 et libavutil52 provenant de testing, pour qu'elles fonctionnent sur une stable. Ce n'est pas nécessairement trivial, bien sûr, mais à mon avis moins délicat que de créer un fichier de préférences pour apt*.
Le plus simple, au fond, c'est de passer à Jessie. Compte tenu du fait que Jessie est en gel, il est possible que tu rencontres des problèmes, en fonction de ton installation (il semble que ceux qui utilisent des lecteurs réseau ou chiffrés, par exemple, aient vécu des problèmes en faisant cette transition, problèmes à priori liés à des défauts dans l'intégration de systemd dans Debian. Je ne sais pas s'ils ont été corrigés) mais, pour une machine de particulier qui ne bricole pas trop, ça ne devrais pas poser de problème.
Ensuite, en terme de complexité selon moi (mais je suis biaisé: je suis développeur), viens la compilation: il y à pas mal de doc sur comment faire sur le net, et il te suffit d'ajouter la ligne deb-src correspondante à Debian Jessie pour que ça marche. Normalement.
L'inconvénient, c'est que tu devras faire les MaJ toi-même, et surveiller toi-même qu'il n'y à pas de maj des paquets source de dispo.
Enfin, vient la solution des preferences. Le truc est suffisamment tortueux à mon avis pour que je ne me sente pas trop chaud à le conseiller à un néophyte. J'ai moi-même merdé plus d'une fois avec ce truc, et j'évite maintenant de le manipuler.
Dans tous les cas, tu devrais signaler ce bug, via l'outil reportbug (ou reportbug-ng).
Simple pour eux donc de lier numéro pass <-> numéro carte <-> nom, prénom <-> liste probable d'adresses via un annuaire
Et sinon, la machine, elle avale la carte? Parce que si oui, y'a plus simple que de faire des recoupements techniques avec d'autres entités: appareil photo dans la machine, reconnaissance des caractères :)
Bref, suis d'accord avec ton anti-paranoïa. La parano ça à du bon, mais il faut faire attention à l'être intelligemment.
[^] # Re: signets synchro? Facile!
Posté par freem . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années…. Évalué à 4.
Allez, juste une précision (foutu timing à la con) sur le gestionnaire de tickets. Parce que, en fait, je te chambrais pas tant que ça, c'est réellement simple à gérer pour faire un truc trivial.
Via xclip. Et ton gestionnaire de fenêtre. Et Xorg.
Tu ne tilte pas?
Avec Xorg, quand tu sélectionnes un texte, il est automatiquement copié dans un presse-papier spécial. Tu colles un binding dans ton gestionnaire de fenêtre, qui utilise xclip pour ajouter le contenu du presse papier du bouton central à la fin d'un fichier HTML, qui n'est pas fini proprement (pas de
</BODY></HTML>donc). Les brouteurs sont assez malins pour s'en sortir de nos jours. T'en fais pas pour eux.Bref, tu as plus qu'à mettre ce fichier en page par défaut ou en signet dans tous tes navigateurs, et le tour est joué. Si tu veux centraliser, tu peux scriptouiller avec ssh pour synchro ce fichier, mais je suis parti pour faire un truc vraiment trivial, la on «complexifie».
Pas super clean, de la bidouille, certes. Mais, sans cahier des charges plus précis que ce que tu as donné, ça semble correspondre à ton besoin. Et me mets pas au défi de faire une arborescence, t'as un super logiciel nommé système de fichier qui sers à faire ce genre de trucs sur ta machine. Hé oui, les fichiers et les dossiers, ça fait des arbres. Donc, y'a moyen de faire un truc plus chiadé, en y passant moins de 4H, qui soit compatible avec tous les brouteurs compatibles Xorg.
Faut juste que celui qui en a besoin se sorte les doigts.
# signets synchro? Facile!
Posté par freem . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années…. Évalué à 6.
Pas moi. Je n'utilise quasiment pas linux, ou plutôt, je ne l'utilise pas de manière consciente. J'utilise Debian, ouai. Linux, uniquement parce qu'il se trouve que c'est le kernel que Debian utilise. Ça pourrait être un BSD, que ça me poserais pas plus de soucis que ça. Ce que j'aime, au fond, c'est les émulateurs de terminal 1000 fois supérieurs à celui de windows, l'interpréteur de commande bash qui est tellement puissant qu'il relègue la souris dans la zone du bureau ou réside la chope à bière, aptitude qui me permets de maintenir mon système au jour le jour sans installer 3 milliards de merdes et sans jamais rien casser… du moins, jamais sans me prévenir que ça va péter.
Rien à voir avec le kernel, vraiment.
Tiens, je pensais que ça existait ce genre de jouets. Les trucs style calendar le font pas? Ils sont donc encore plus inutiles que je ne le pensais, c'est triste.
C'est clair, ça serait pas mal.
Le problème, c'est que pour ça, il faudrait… hem… faire un truc extrêmement difficile pour un éco-système dont la force vient de la diversité: standardiser. Uniformiser. Pour créer une API acceptée par tous les développeurs, y compris les NIH (dont je fait partie, je le sais et je n'en ai pas honte) qui codent pour le fun (voila pourquoi j'en ai pas honte) des applications que d'autres sont libres d'utiliser ou pas.
En fait, il faudrait un PulseAudio pour le réseau. Sauf que le réseau, il est bien plus complexe à gérer que le son, puisqu'il dépend pas mal de l'extérieur. Pour ne pas dire complètement. Et PA semble avoir causé pas mal de remous comme ça… de remous et de casse si j'en crois mes lectures (mais on ne lis que ceux qui ont eu des problèmes, donc…).
Pour finir d'enfoncer des portes ouvertes… c'est au navigateur de savoir gérer sa bande passante correctement. Je doute que tu utilises 20 000 logiciels pour squatter ton réseau, pas vrai? En gros, je vois 2 types de logiciels qui exploitent régulièrement le réseau sur une machine personnelle: le brouteur, et un gestionnaire de téléchargement. Très sincèrement, c'est clair: si seulement les brouteurs intégraient un gestionnaire de téléchargement digne de ce nom, ça serait tellement plus confortable. Bon, ça réglèrai pas le problème d'apt qui squatte toute la bp quand on lance une maj, mais… ça serait déjà pas mal. Mais, pas la faute à Linux, ni même aux distros ça: ils préfèrent se concentrer sur le tape-à-l'œil, le chteumeuleu 5, pour faire plaisir à ceux qui ne savent pas trop ce dont il s'agit et ne peuvent s'empêcher de cliquer là ou ça gigote.
Hum… Si je ne m'abuse, il est trivial d'ajouter à un fichier (echo foo >> my_file) une ligne contenant un lien. Bon, ok, je chambre un poil. Certes. Mais, ce problème n'est lié ni à linux, ni à windows, ni à quelque démon obscur. Juste au fait que les navigateurs se font la guerre.
Et personne n'oserai repprocher à mozilla ou chromium de ne pas être compatibles entre eux pour leurs données internes, pas vrai?
Ah, mais, c'est ta faute ça. Pourquoi n'utilises-tu donc pas que des applications qui suivent FreeDesktopOrg? Beaucoup le font. Il ne doit pas en rester tant que ça qui ne le font pas, excepté les trucs de barbus genre vim, bash & co. Et je doute fort que les patcher soit si difficile pour changer une localisation de fichier de config, si vraiment tu ne peux te passer de ces outils (comme moi) et que ça te gêne tant que ça (pas comme moi).
Enfin bon, si je comprend bien, tu aimerais que ton bureau, te répondes au doigt et à l'œil? Et ce, sans avoir à le customiser au p'tits oignons toi-même?
Je meurs d'envie de répondre qu'il y à déjà les outils pour faire ce dont tu rêves, mais que la seule chose qui fait que ce n'est pas encore fini, c'est que ça manque de volontaire… mais on m'accuserai de te provoquer j'imagine.
Perso, j'ai trouvé une solution très acceptable: j'ai fabriqué mon DE à partir de pièces détachées trouvées dans aptitude. Ça marche super bien, c'est hyper léger, hyper réactif, je contrôle tout du bout des doigts sans bouger les poignets, c'est… le pied, si j'ose dire :)
Bref, sors-toi les doigts, la solution la plus adaptée à tes besoins existe déjà, il faut juste que tu mettes les pièces ensemble. Si tu as la flemme, très bien, mais assumes ton choix de ne pas investir ton temps pour en perdre moins par la suite. Et si d'aventure je me trompais, si tous les logiciels dont tu as besoin n'existent pas, je t'encourage à les créer, que ce soit pas toi-même, ou en les faisant faire, d'une manière ou d'une (oui, ça peut vouloir dire embaucher des gens, mais, après tout, c'est pour ton confort personnel), par les autres.
[^] # Re: .
Posté par freem . En réponse au sondage Mon processeur préféré ?. Évalué à 4.
Ben, non en fait.
Tiens, moi aussi. Et justement, c'est là que j'ai commencé à bidouiller la mémoire et le mode 13H en fait.
DEF SEG = A000: POKE foobar, 255ou un truc du genre pour allumer le pixel foobar en blanc, non? On pouvait aussi appeler du code C ou ASM de cette façon si ma mémoire ne m'abuse.Je ne serai donc jamais un pro. Tant pis :) Pas sûr de le regretter, de n'être pas considéré comme pro, à bien y réfléchir.
Malheureusement, je n'ai fait de l'assembleur que parce que je suis auto-didacte, le discours quand j'étais à l'école (ça remonte maintenant, pas loin de 10 ans, déjà :/) c'était plutôt: «laisser le client racheter du matos, collez donc des int pour stocker des char». J'étais en BTS IRIS, le successeur du BTS info indus selon les profs. Ça m'à écœuré du code pendant plus d'un an après ma sortie des études leurs discours. Et le fait que 80% des TPs consistaient à manipuer l'IHM de VS pour dessiner des fenêtres…. beurk! Ça doit expliquer en partie mon aversion actuelle pour les IHMs j'imagine.
Mon opinion sur ce sujet est trop embrouillée pour être exprimée sur un forum.
# customisation du boot
Posté par freem . En réponse au message Installer Debian directement sur le SSD ?. Évalué à 2.
Modifier le boot de ton PC installeur pour qu'il démarre sur une iso d'installation. C'est le plus simple, et c'est d'ailleurs ce que je fait sur un de mes disques durs externes: multi boot, install de debian 32, 64 bits, install de netbsd (que j'ai pas encore utilisé d'ailleurs), boot sur debian 32 ou 64 bits. Choix au démarrage, comme il se doit. Configuré via Lilo, avec grub j'ai trouvé la doc bien trop bordélique.
Un p'tit disque dur bootable presque partout quoi :)
[^] # Re: Intérêt
Posté par freem . En réponse au message Installer Debian directement sur le SSD ?. Évalué à 3. Dernière modification le 12 mai 2015 à 16:16.
Tout le monde ne sait pas configurer un boot réseau…
# utilise le gestionnaire de paquet de ta distribution
Posté par freem . En réponse au message N'installer qu'une partie de Cinnamon. Évalué à 2.
Il te faut identifier le nom du paquet contenant le logiciel que tu veux, et l'installer via ton gestionnaire de paquets.
Dans le cas de mint, c'est basé sur Debian, donc, moi, ce que je ferai, c'est que je lancerai aptitude (via un terminal), pour chercher (touche '/') les paquets installés contenant les mots qui m'intéressent sur la machine qui l'utilise. Tu peux aussi utiliser l'arborescence, c'est plus long mais ça sera peut-être plus simple pour quelqu'un qui n'est pas habitué.
# versions des paquets
Posté par freem . En réponse au message carte graphique intégrée et instabilité d'affichage. Évalué à 2.
Je ne suis sûr d'avoir tout compris, ton message n'est pas très clair à ce sujet.
Avec le DE mate, sous Debian Jessie tu as le problème.
Idem avec XFCE, même système.
Avec le pilote proprio, ça marche mais plus au bout d'un certain nombre de redémarrage.
Avec le DE gnome, sous Debian Squeeze (l'ancienne old-stable, quand même) et pilote propriétaire c'est stable?
Dans ce cas, je dirais, problème d'accélération graphique, essaie de la désactiver. Ou de vérifier que tes pilotes sont à jour.
Si j'ai mal compris, j'imagine qu'il va falloir reformuler :)
[^] # Re: BSD Owl, ton prochain système de build
Posté par freem . En réponse au message lancer un shell "vierge" dans un nouveau terminal. Évalué à 2.
Des macros, surtout. Un inceste avec le C, peut-être? Faut que je trouve le temps de tester ton truc… toujours pas fait
[^] # Re: CMAKE_BUILD_TYPE=Debug
Posté par freem . En réponse au message [Résolu] valgrind & cmake. Évalué à 2.
C'est juste que le manuel conseillait de mettre en O1 en fait.
[^] # Re: .
Posté par freem . En réponse au sondage Mon processeur préféré ?. Évalué à 10.
Dans le bon sens du terme? Vraiment? Je ne suis pas convaincu, le fun ne dépend pas de la complexité. D'ailleurs, à l'heure actuelle, la plupart de la complexité se situe au niveau du GPU pour le coup, à grands coups de maths. Erk.
Après, au niveau des programmes eux-mêmes, je les trouve régulièrement inutilement complexes. Il y à d'ailleurs un certain nombre de personnes en prog qui favorisent le principe du Keep It Simple and Stupid. Ce n'est pas pour rien.
Non, l'époque (pas si lointaine, un peu plus d'une décennie) ou je tapais mes premières lignes de code et apprenais à désassembler des binaires ne m'évoque pas de bons souvenirs que pour la nostalgie, mais aussi parce que, bon sang, c'était tellement plus simple à l'époque de faire des trucs simples en programmation!
À l'heure actuelle, pour réussir à allumer 1 pixel, il faut se taper une bibliothèque… non, pire en fait, un framework complet… À l'époque ou l'accès au matos était direct, il suffisait de quelques lignes d'assembleur, de l'ordre de quelques 10aine (une interruption pour changer le mode graphique, genre le 0x13, puis balancer les données direct dans A000:0000. Si mes souvenirs sont bons.).
Pas sûr que je serai toujours barré dans le code si je n'avais commencé avec une technologie certes obsolète à l'époque (ben oui, le mode réel en 2002-2003, c'était un poil obsolète) mais assez simple pour être comprise par le plus grand débutant. J'ai commencé l'informatique tard, et je n'avais rien d'un informaticien à ce moment là, j'étais plus un rat de bibliothèque…
Quand je vois le mal que mes profs d'info ont eu (2006-2007) à expliquer aux autres ce qu'était un pointeur ensuite, alors que la plupart des gens venaient de STI électronique, je me demande si commencer par du matos et des techniques obsolètes mais simples n'a pas un certain intérêt.
[^] # Re: Les repères, ça compte!
Posté par freem . En réponse au journal elementaryOS, une distribution aux nombreuses qualités. Évalué à 3.
Penses à la nature et au porte-feuille: pourquoi graver des .iso, quand on peut booster une iso à partir d'une clé USB? En plus, ça sera probablement plus rapide qu'un lecteur DVD.
Ma foi, il arrive souvent que pour les questions les plus simples, la réponse soit presque la même pour toutes les distributions. Debian, Ubuntu, ou autre, peu importe si la question concerne une application avec interface graphique j'ai l'impression.
Probablement. De la même façon que ce qui marche pour Debian marche pour Ubuntu. Peu importe la distribution, l'important c'est plus l'environnement graphique (pour un débutant du moins) que ce qu'il y à sous le capot.
[^] # Re: Console Linux vs XTerm
Posté par freem . En réponse au sondage Quel terminal utilisez-vous ?. Évalué à 3.
gpm? C'est quoi?
En tout cas, si tu as réussi à le lancer en TTY, je suis preneur de la procédure (suis sous Debian old-stable moi. Pas trop sûr de vouloir passer à Jessie, de toute façon ça n'urge pas). Ce navigateur m'intéresse, et pas juste pour ça: le fait que le moteur de rendu ne soit pas un des grands classiques et qu'ils visent la légèreté m'intéresse très fortement.
[^] # Re: BSD Owl, ton prochain système de build
Posté par freem . En réponse au message lancer un shell "vierge" dans un nouveau terminal. Évalué à 2.
Comment ai-je pu ne pas penser à un truc aussi évident… Merci! Plus qu'a filer à bash les arguments pour spécifier quels fichiers de conf lire, et c'est nickel (trivial, bash à au moins un man clair).
Intéressant, j'y jetterai un œil, même si j'ai un mauvais apriori des Makefile. Ça pourra me filer des idées ou même me convaincre que finalement, «les Makefile,c'est trivial». Pointe d'humour, mais si je n'aime pas les makefile, c'est surtout que je les trouve illisibles. Sans parler du fait qu'il y ait une différence syntaxique entre les divers caractères blancs, c'est typiquement le genre de trucs qui me fait tiquer. Et la raison principale pour laquelle me suis pas encore essayé au python.
Je ne savais pas qu'il y avait tant de différences que ça.
Le pire, c'est que tu vas me convaincre… c'est bon ça! concis! lisible! maintenable (à première vue du moins)!! Bon, demain férié, rien à faire à part zoner sur le net ou coder, bah je pense que je vais tester. Sûrement tester ce soir aussi, pour le coup (je devrais être capable d'installer/tester netBSD sur une autre machine en même temps, ce que j'avais prévu comme programme pour la soirée héhé).
[^] # Re: Peut-être qu'avec ça ...
Posté par freem . En réponse au message lancer un shell "vierge" dans un nouveau terminal. Évalué à 2.
Le problème, c'est que ça ne supprime pas les variables. Le shell enfant hérite des variables de son parent, ces deux options permettent simplement de sauter les fichiers de configuration.
[^] # Re: réponse rapide
Posté par freem . En réponse au message Licence LGPL & GPL. Évalué à 2.
Petit complément sur la compatibilité des licences:
La licence MIT est compatible avec la licence GPL parce qu'elle est moins contraignante, la GPL pouvant avoir des incompatibilité avec d'autres licences à cause de sa viralité.
Dans le cas d'un logiciel qui serait écrit sous une licence MIT mais utiliserais une licence GPL, il serait obligatoire de distribuer le source du logiciel (aux utilisateurs du dit logiciel, pas au monde entier! Ces utilisateurs en revanche auraient le droit d'en faire ce qu'ils veulent, notamment refiler le code au monde entier…), malgré sa licence MIT, à cause de cette viralité. Le seul intérêt de faire cela serait donc le fait qu'il serait possible de stopper la diffusion du code une fois la dépendance à la GPL supprimée.
L'inverse, c'est à dire utiliser une licence MIT dans un projet GPL, reviens au même, sauf que l'on est pas obligé de distribuer le code de la bibliothèque.
Enfin, dans le cas de la LGPL, distribuer le source du logiciel n'est obligatoire, de mémoire, que si l'édition des liens s'est faite de manière statique, c'est à dire que la bibliothèque et le programme ne représentent qu'un seul binaire. Dans le cas de l'édition dynamique (DLL pour windows, so pour linux), cette contrainte disparaît.
Bon, c'est assez brut comme explication, pas hyper précis, encore moins exhaustif, et je me trompe peut-être même sur certains points. Je ne suis pas légiste, et sincèrement, la GPL me semble s'être encore compliquée avec sa version 3… maintenant je préfère utiliser des licences type BSD, au moins ça tiens en même pas 10 lignes, c'est clair, et pas prise de tête à gérer. Pas comme si mes bouts de code étaient difficile à reproduire, voire refaire en mieux de toute façon :D
[^] # Re: Tilda .... sur le côté de l'écran
Posté par freem . En réponse au sondage Quel terminal utilisez-vous ?. Évalué à 3.
En général, c'est plutôt l'hyper-espace il faut dire.
Je suis déjà dehors :p
[^] # Re: Console Linux vs XTerm
Posté par freem . En réponse au sondage Quel terminal utilisez-vous ?. Évalué à 3.
Ce n'est pas firefox, il manque encore un bon support de JS (de mémoire, faudrait que je reteste), mais tu seras peut-être intéressé par netsurf.
Sous Debian, j'ai 2 paquets principaux: netsurf-fb pour le framebuffer, et netsurf-gtk.
Par contre, j'avoue n'avoir jamais testé la moindre application graphique sous une TTY, et la, un rapide test tant avec mplayer qu'avec netsurf me fait penser qu'il y à de la config à faire, ou je ne sais quoi.
Faudra que je m'y mette un jour, ça peut servir.
[^] # Re: WTF
Posté par freem . En réponse au journal Libérer le comptoir du hardware V2. Évalué à 4.
Sans même parler des moules, un comble!
[^] # Re: debian sid
Posté par freem . En réponse au message LMDE 2 -> Debian testing. Évalué à 3.
Il y à eu plusieurs discussions sur la ML Debian également sur le sujet de la sécurité. Testing était également considérée comme la pire version de ce point de vue. Ceci dit, il me semble que depuis un dépôt security à été créé pour testing.
[^] # Re: Oui
Posté par freem . En réponse au message [Résolu] valgrind & cmake. Évalué à 2.
Super merci!
Je vais pouvoir enfin essayer de jouer avec valgrind du coup (reste à apprendre à s'en servir correctement, mais j'imagine que ça viendra avec la pratique ça).
# 2 solutions
Posté par freem . En réponse au message Installer un package en sid. Évalué à 3.
Je vois plusieurs solutions perso.
1) ajouter le dépôt de Jessie, aka testing, pour installer les lib manquantes. Le problème, c'est qu'il te faudra très probablement mettre à jour certains paquets qui forment le coeur du système. Et si tu veux éviter de mettre à jour le système entier, il te faudra jouer avec le fichier /etc/apt/preferences (ou ajouter un fichier du même type dans /etc/apt/preferences.d, au choix) ce qui n'est pas vraiment trivial.
2) compiler les libs libavcodec54 (ou libavcodec-extra-54, au choix), libavformat54, libavresample1 et libavutil52 provenant de testing, pour qu'elles fonctionnent sur une stable. Ce n'est pas nécessairement trivial, bien sûr, mais à mon avis moins délicat que de créer un fichier de préférences pour apt*.
Le plus simple, au fond, c'est de passer à Jessie. Compte tenu du fait que Jessie est en gel, il est possible que tu rencontres des problèmes, en fonction de ton installation (il semble que ceux qui utilisent des lecteurs réseau ou chiffrés, par exemple, aient vécu des problèmes en faisant cette transition, problèmes à priori liés à des défauts dans l'intégration de systemd dans Debian. Je ne sais pas s'ils ont été corrigés) mais, pour une machine de particulier qui ne bricole pas trop, ça ne devrais pas poser de problème.
Ensuite, en terme de complexité selon moi (mais je suis biaisé: je suis développeur), viens la compilation: il y à pas mal de doc sur comment faire sur le net, et il te suffit d'ajouter la ligne deb-src correspondante à Debian Jessie pour que ça marche. Normalement.
L'inconvénient, c'est que tu devras faire les MaJ toi-même, et surveiller toi-même qu'il n'y à pas de maj des paquets source de dispo.
Enfin, vient la solution des preferences. Le truc est suffisamment tortueux à mon avis pour que je ne me sente pas trop chaud à le conseiller à un néophyte. J'ai moi-même merdé plus d'une fois avec ce truc, et j'évite maintenant de le manipuler.
Dans tous les cas, tu devrais signaler ce bug, via l'outil reportbug (ou reportbug-ng).
[^] # Re: mauvaise relation de cause a effet
Posté par freem . En réponse au journal techos bradés. Évalué à 4.
Imagines les homo athées :)
[^] # Re: ya des bornes
Posté par freem . En réponse au journal Pass Navigo et Linux ... Grmbl .... Évalué à 3.
Et sinon, la machine, elle avale la carte? Parce que si oui, y'a plus simple que de faire des recoupements techniques avec d'autres entités: appareil photo dans la machine, reconnaissance des caractères :)
Bref, suis d'accord avec ton anti-paranoïa. La parano ça à du bon, mais il faut faire attention à l'être intelligemment.
[^] # Re: carte SD
Posté par freem . En réponse au message Merci A tous . Évalué à 2.
Autres endroits ou regarder: /etc/cron*
[^] # Re: .
Posté par freem . En réponse au journal NuTyX, une distribution atypique . Évalué à 2.
Dans l'idée de sta.li en fait? Il y en a d'autres, probablement à des stades plus avancés…