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.
Faux. En tout cas, pour Debian et ses filles, c'est faux: certains paquets sont marqués essentiels, et nécessitent de taper une phrase complète si l'on veut les supprimer. Par exemple: le système d'init.
La priorité est bel et bien un paramètre qui permet de dire que tel ou tel paquet ne sont pas supprimables… enfin, ils le sont, mais le système te préviens que tu es probablement en train de faire une connerie. De même, même s'ils sont marqués installés automatiquement et que rien ne dépend d'eux, ils ne seront pas désinstallés automatiquement.
Du coup, je considère qu'on peut parler de statut à part pour ces paquets (puisque tout système --Debian--, excepté un système modifié par quelqu'un qui sait vraiment ce qu'il fait, aura ces paquets installés).
Pour Windows, il y à tout ce qui touche au Framework .NET, qui est utilisé par un grand nombre de logiciel mais n'est pas nécessairement installé (à moins que ça ait changé) voire même, on peut le virer, en tout ou partie.
Quant au pari… dans le cas de Windows, soyons sérieux un instant: quand j'installe une application tierce, il est bien rare qu'il n'y ait pas de DLL livrée avec. Cette DLL est peut-être utilisée par d'autres applications… et si ce n'est pas le cas, alors il n'y à aucune raison que ce soit une DLL, pas vrai? Si je me trompe, alors Windows à bien changé depuis que j'ai eu à en bidouiller un pour la dernière fois. Entre nous, ça serait pas plus mal.
Pour Mac OS X ou pour les BSD, je n'ai pas la moindre idée de comment ça marche.
L'enfer des dépendances à un nom. Plusieurs, même, mais perso je ne connais que celui donné "affectueusement" par les power user de Windows: DLL Hell.
Donc, tes paquets qui marchent nickel pour toutes les versions de Windows, j'ai envie de dire: "oula, ça dépend. Si tu embarques les 200Mio de données de trucs potentiellement déjà installés sur le système, ouai, ok, parce que sinon bienvenue dans l'enfer des dépendances."
Bon, soyons honnêtes, ce problème existe sous tous les systèmes. En fait, dès lors qu'on utilise de l'édition de liens dynamique, on s'expose aux emmerdes. Version de glibc qui change, par exemple (pour de bonnes raisons: patchs de sécu… d'un autre côté, on aurait peut-être moins besoin de la changer si elle n'avait pas d'extensions et se contentait d'implémenter le standard… mais c'est un autre sujet, très vaste.).
La solution classique sous Windows, c'est de foutre toutes les DLL nécessaires dans le dossier d'install. ça marche, sans bidouille, mais en fait, cette solution est d'une dégueulasserie énorme, qui expose l'utilisateur à des failles de sécurités nommées: hooks. Un attaquant peut du coup très bien mettre une DLL qui à le même nom qu'une DLL système dans ce dossier, pour… hé bien, faire tout ce qui lui plaît. C'est d'ailleurs la technique utilisée par un programme pour améliorer le moteur graphique original de morrowind. Sous les distrib Linux que j'ai testées, cette solution impose d'avoir un script shell pour modifier le LD_LIBRARY_PATH, ou un truc dans le genre, avant de lancer l'exécutable. Mais ça marche.
Bon, en général, on préfère la production de paquets pour les distributions, justement pour éviter l'enfer de l'édition dynamique des liens. Question de choix.
Mais, il existe une autre solution, mille fois plus propre, valide pour TOUS les systèmes: édition des liens de manière statique.
Oui, ça implique de se trimballer toutes les dépendances, mais en plus léger: seuls les symboles réellement utiles seront inclus dans le "paquet", contrairement à ce qui se passe quand on se trimballe les lib dynamiques. Du coup, réduction du risque d'erreurs: on ne peux pas oublier de DLL (le fichier msvcfoo.dll n'à pas été trouvé, réinstaller cette application pourrait corriger le problème… merde, 3 fois que je réinstalle, ça change rien!!!! graaa!!!! SBAF dans l'écran! moi j'ai connu. Et vous?), réduction des risques de sécurité.
Ah, réduction des risques de sécurité… pas si sûr, au final, parce que cette politique est hermétique aux bidouilleurs et admin: on ne peut pas corriger une faille de sécurité sans tout recompiler. Hors, ça, ça implique de compiler à chaque MàJ des dépendances… ce qui représente du travail. Mais ça reste quand même moins sensible que la solution "on embarque toutes les DLLs et basta!": le risque qu'un symbole attaquable soit inclus est plus faible, et on est aussi plus résistants aux hooks.
(Ma) conclusion:
1) faire un paquet portable sous linux, ça se fait. De manière très simple: édition des liens statique (surtout pour cette saleté de gnu libc. D'ailleurs, c'est très drôle de réécrire la commande yes, compiler en statique, et comparer à la taille de gnu yes…).
2) la pratique habituelle des "paquets" Windows à contribué à filer à Windows sa mauvaise réputation en matière de sécurité, rendant vulnérable les applications aux hooks, et donc aux virus. D'un autre côté, rien n'empêche de faire la même merde avec un autre système. La merde n'est pas l'apanage de Windows, mais l'habitude d'en faire me semble nettement plus ancrée dans la culture de ce système. Pas la faute des Windows récents, certes.
3) les systèmes de paquets des distributions Linux classiques sont nettement supérieurs à la méthode de La Rache utilisée sous Windows. Mais, comme toute solution elle implique des inconvénients, dont la faible portabilité fait partie (pour un paquet binaire hein, très important).
Et pour en revenir au sujet de base, à savoir la naissance d'une nouvelle distro basée sur LFS, autrement dit basée sur rien, c'est très bien, ça permets à l'auteur de s'amuser. Et à d'autres de s'amuser avec lui.
Mais personne n'est dupe: cette distro ne pourra jamais concurrencer les ténors actuels et leurs enfants: Debian, Red-Hat, ArchLinux. Pas tout de suite en tout cas, et puis, le seul avantage affiché étant la vitesse supposée, je meurs d'envie de dire: benchmark? tests de charge?
Il me semble aussi stupide de conseiller une telle distro à des nouveaux utilisateurs linux. Mais on ne va pas enfoncer les portes ouvertes quand même, si? Il est évident que la jeunesse (manque de robustesse du au manque de recul et de plateformes de tests) est un défaut, quand on s'adresse à un public non connaisseur.
Attention, enfonçage de portes ouvertes. Mais pour certains ça semble nécessaire.
1) (admettons que) tu installes un système propriétaire.
T'as 1 licence pour une quantité de logiciels non négligeables (outils système, kernel, pilotes) pour l'OS.
T'as ensuite 1 licence pour chaque soft installé supplémentaire, et au boulot en fait, t'en installes pas tant que ça (hors outils de confort, donc hors navigateur puisque t'en a un par défaut par exemple. Idem l'éditeur de texte, la console, et probablement d'autres, suis pas expert Mac OS ou Windows, peut pas tout citer.).
Pardon, pas pour chaque soft: pour chaque produit, qui peuvent inclure plusieurs softs (la suite Visual Studio, les suites de bureautique, etc).
Mieux: il y à fort à parier (j'ai pas les moyens de vérifier) que les entreprises utilisent souvent le même CLUF pour tous leurs produits: donc, avantage à utiliser des produits Microsoft ou Apple au maximum, du coup.
Nettement plus simple à gérer que pour une distribution GNU/Linux si tu veux être carré donc. Et les entreprises prudentes, elles sont carrées. Pas les particuliers, certes. Jusqu'au jour ou une emmerde te tombe sur le coin du nez du moins (j'en connais qui ont arrêté le téléchargement illégal après avoir reçu un courrier notamment. Ils ont arrêté avant de risque d'être emmerdés.).
2) (admettons que) tu contribues à un logiciel (libre ou pas, peu importe, c'est ton choix).
Il utilise une licence que tu connais, style GPL, LGPL, BSD: tu sais à peu près à quoi t'attendre sur le devenir de ta contribution.
Il utilise une licence écrite sans être ridicule et grossière (style pas celle du journal quoi): tu peux la lire et comprendre à peu près à quoi ça t'engagerai devant un tribunal. Regardes bien: dans les commentaires, quelqu'un à fait remarquer la licence débile n'est pas libre, du fait qu'elle décourage l'utilisation commerciale. Mais, se contente-t-elle de décourager, ou d'interdire? C'est la preuve que la prolifération des licences stupides est un risque de grosses emmerdes pour un éventuel contributeur ou utilisateur.
Il y à nombre d'accords internationaux, et sans aller jusqu'au niveau du monde entier, l'UE promulgue des lois, je doute qu'elles soient toutes écrites dans toutes les langues de tous les pays membre. Après, peut-être que quelqu'un les traduit et les mets à dispo, mais j'ai un doute.
[^] # 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…
[^] # Re: pas de systemd, et ?
Posté par freem . En réponse au journal NuTyX, une distribution atypique . Évalué à 2.
Faux. En tout cas, pour Debian et ses filles, c'est faux: certains paquets sont marqués essentiels, et nécessitent de taper une phrase complète si l'on veut les supprimer. Par exemple: le système d'init.
La priorité est bel et bien un paramètre qui permet de dire que tel ou tel paquet ne sont pas supprimables… enfin, ils le sont, mais le système te préviens que tu es probablement en train de faire une connerie. De même, même s'ils sont marqués installés automatiquement et que rien ne dépend d'eux, ils ne seront pas désinstallés automatiquement.
Du coup, je considère qu'on peut parler de statut à part pour ces paquets (puisque tout système --Debian--, excepté un système modifié par quelqu'un qui sait vraiment ce qu'il fait, aura ces paquets installés).
Pour Windows, il y à tout ce qui touche au Framework .NET, qui est utilisé par un grand nombre de logiciel mais n'est pas nécessairement installé (à moins que ça ait changé) voire même, on peut le virer, en tout ou partie.
Quant au pari… dans le cas de Windows, soyons sérieux un instant: quand j'installe une application tierce, il est bien rare qu'il n'y ait pas de DLL livrée avec. Cette DLL est peut-être utilisée par d'autres applications… et si ce n'est pas le cas, alors il n'y à aucune raison que ce soit une DLL, pas vrai? Si je me trompe, alors Windows à bien changé depuis que j'ai eu à en bidouiller un pour la dernière fois. Entre nous, ça serait pas plus mal.
Pour Mac OS X ou pour les BSD, je n'ai pas la moindre idée de comment ça marche.
[^] # Re: Il y a des projets de lois mais aussi des lois déjà passées
Posté par freem . En réponse au journal Dark side of the law. Évalué à 3.
C'est un sketch des inconnus, celui ou ils jouent des publicitaires.
[^] # Re: pas de systemd, et ?
Posté par freem . En réponse au journal NuTyX, une distribution atypique . Évalué à 4.
L'enfer des dépendances à un nom. Plusieurs, même, mais perso je ne connais que celui donné "affectueusement" par les power user de Windows: DLL Hell.
Donc, tes paquets qui marchent nickel pour toutes les versions de Windows, j'ai envie de dire: "oula, ça dépend. Si tu embarques les 200Mio de données de trucs potentiellement déjà installés sur le système, ouai, ok, parce que sinon bienvenue dans l'enfer des dépendances."
Bon, soyons honnêtes, ce problème existe sous tous les systèmes. En fait, dès lors qu'on utilise de l'édition de liens dynamique, on s'expose aux emmerdes. Version de glibc qui change, par exemple (pour de bonnes raisons: patchs de sécu… d'un autre côté, on aurait peut-être moins besoin de la changer si elle n'avait pas d'extensions et se contentait d'implémenter le standard… mais c'est un autre sujet, très vaste.).
La solution classique sous Windows, c'est de foutre toutes les DLL nécessaires dans le dossier d'install. ça marche, sans bidouille, mais en fait, cette solution est d'une dégueulasserie énorme, qui expose l'utilisateur à des failles de sécurités nommées: hooks. Un attaquant peut du coup très bien mettre une DLL qui à le même nom qu'une DLL système dans ce dossier, pour… hé bien, faire tout ce qui lui plaît. C'est d'ailleurs la technique utilisée par un programme pour améliorer le moteur graphique original de morrowind. Sous les distrib Linux que j'ai testées, cette solution impose d'avoir un script shell pour modifier le LD_LIBRARY_PATH, ou un truc dans le genre, avant de lancer l'exécutable. Mais ça marche.
Bon, en général, on préfère la production de paquets pour les distributions, justement pour éviter l'enfer de l'édition dynamique des liens. Question de choix.
Mais, il existe une autre solution, mille fois plus propre, valide pour TOUS les systèmes: édition des liens de manière statique.
Oui, ça implique de se trimballer toutes les dépendances, mais en plus léger: seuls les symboles réellement utiles seront inclus dans le "paquet", contrairement à ce qui se passe quand on se trimballe les lib dynamiques. Du coup, réduction du risque d'erreurs: on ne peux pas oublier de DLL (le fichier msvcfoo.dll n'à pas été trouvé, réinstaller cette application pourrait corriger le problème… merde, 3 fois que je réinstalle, ça change rien!!!! graaa!!!! SBAF dans l'écran! moi j'ai connu. Et vous?), réduction des risques de sécurité.
Ah, réduction des risques de sécurité… pas si sûr, au final, parce que cette politique est hermétique aux bidouilleurs et admin: on ne peut pas corriger une faille de sécurité sans tout recompiler. Hors, ça, ça implique de compiler à chaque MàJ des dépendances… ce qui représente du travail. Mais ça reste quand même moins sensible que la solution "on embarque toutes les DLLs et basta!": le risque qu'un symbole attaquable soit inclus est plus faible, et on est aussi plus résistants aux hooks.
(Ma) conclusion:
1) faire un paquet portable sous linux, ça se fait. De manière très simple: édition des liens statique (surtout pour cette saleté de gnu libc. D'ailleurs, c'est très drôle de réécrire la commande yes, compiler en statique, et comparer à la taille de gnu yes…).
2) la pratique habituelle des "paquets" Windows à contribué à filer à Windows sa mauvaise réputation en matière de sécurité, rendant vulnérable les applications aux hooks, et donc aux virus. D'un autre côté, rien n'empêche de faire la même merde avec un autre système. La merde n'est pas l'apanage de Windows, mais l'habitude d'en faire me semble nettement plus ancrée dans la culture de ce système. Pas la faute des Windows récents, certes.
3) les systèmes de paquets des distributions Linux classiques sont nettement supérieurs à la méthode de La Rache utilisée sous Windows. Mais, comme toute solution elle implique des inconvénients, dont la faible portabilité fait partie (pour un paquet binaire hein, très important).
Et pour en revenir au sujet de base, à savoir la naissance d'une nouvelle distro basée sur LFS, autrement dit basée sur rien, c'est très bien, ça permets à l'auteur de s'amuser. Et à d'autres de s'amuser avec lui.
Mais personne n'est dupe: cette distro ne pourra jamais concurrencer les ténors actuels et leurs enfants: Debian, Red-Hat, ArchLinux. Pas tout de suite en tout cas, et puis, le seul avantage affiché étant la vitesse supposée, je meurs d'envie de dire: benchmark? tests de charge?
Il me semble aussi stupide de conseiller une telle distro à des nouveaux utilisateurs linux. Mais on ne va pas enfoncer les portes ouvertes quand même, si? Il est évident que la jeunesse (manque de robustesse du au manque de recul et de plateformes de tests) est un défaut, quand on s'adresse à un public non connaisseur.
[^] # Re: multiplication des licences... pourquoi tout le monde réinvente la roue?
Posté par freem . En réponse au journal Licence open source "Don't Be a Jerk". Évalué à 4.
Attention, enfonçage de portes ouvertes. Mais pour certains ça semble nécessaire.
1) (admettons que) tu installes un système propriétaire.
T'as 1 licence pour une quantité de logiciels non négligeables (outils système, kernel, pilotes) pour l'OS.
T'as ensuite 1 licence pour chaque soft installé supplémentaire, et au boulot en fait, t'en installes pas tant que ça (hors outils de confort, donc hors navigateur puisque t'en a un par défaut par exemple. Idem l'éditeur de texte, la console, et probablement d'autres, suis pas expert Mac OS ou Windows, peut pas tout citer.).
Pardon, pas pour chaque soft: pour chaque produit, qui peuvent inclure plusieurs softs (la suite Visual Studio, les suites de bureautique, etc).
Mieux: il y à fort à parier (j'ai pas les moyens de vérifier) que les entreprises utilisent souvent le même CLUF pour tous leurs produits: donc, avantage à utiliser des produits Microsoft ou Apple au maximum, du coup.
Nettement plus simple à gérer que pour une distribution GNU/Linux si tu veux être carré donc. Et les entreprises prudentes, elles sont carrées. Pas les particuliers, certes. Jusqu'au jour ou une emmerde te tombe sur le coin du nez du moins (j'en connais qui ont arrêté le téléchargement illégal après avoir reçu un courrier notamment. Ils ont arrêté avant de risque d'être emmerdés.).
2) (admettons que) tu contribues à un logiciel (libre ou pas, peu importe, c'est ton choix).
Il utilise une licence que tu connais, style GPL, LGPL, BSD: tu sais à peu près à quoi t'attendre sur le devenir de ta contribution.
Il utilise une licence écrite sans être ridicule et grossière (style pas celle du journal quoi): tu peux la lire et comprendre à peu près à quoi ça t'engagerai devant un tribunal. Regardes bien: dans les commentaires, quelqu'un à fait remarquer la licence débile n'est pas libre, du fait qu'elle décourage l'utilisation commerciale. Mais, se contente-t-elle de décourager, ou d'interdire? C'est la preuve que la prolifération des licences stupides est un risque de grosses emmerdes pour un éventuel contributeur ou utilisateur.
[^] # Re: Licence DBAD
Posté par freem . En réponse au journal Licence open source "Don't Be a Jerk". Évalué à 2.
Ah ça, la remettre droit est un vrai travail d'homme :)
[^] # Re: Licence DBAD
Posté par freem . En réponse au journal Licence open source "Don't Be a Jerk". Évalué à 3.
Ce qui est plutôt ironique non?
[^] # Re: Licence DBAD
Posté par freem . En réponse au journal Licence open source "Don't Be a Jerk". Évalué à 2.
Il y à nombre d'accords internationaux, et sans aller jusqu'au niveau du monde entier, l'UE promulgue des lois, je doute qu'elles soient toutes écrites dans toutes les langues de tous les pays membre. Après, peut-être que quelqu'un les traduit et les mets à dispo, mais j'ai un doute.