bah j'avais fait "reveil matin OS X" dans google et j'étais tombé la dessus :P
J'avais décidé d'aller jusqu'au bout, histoire de voir si cette solution se revelait être finalement pratique et puissante ou pas.
Je suis ravi de voir qu'une solution plus simple existe pour ce problème précis, vu qu'il est assez courant. Le truc c'est qu'on est intrinsèquement limité par la liste des choix dispo. Difficile de régler le nivau du son avant de lancer la lecture audio sans passer par Automator par exemple (en restant dans le tout graphique bien sûr).
En fait je n'ai rien contre les IHM graphiques lorsqu'elles sont bien conçus et réalisent des opérations moyennement complexe et extrèmement courantes. Mais pour faire des choses assez complexes et potentiellement extensible sans abuser de son imagination (hors traitement intrinsèquement graphique), je constate habituellement qu'on obtient des usines à gaz, ou alors un truc à moitié fonctionnel et en tout cas pas évolutif, dans lequel on ne peut pas combiner des opérations existentes librement.
- ptetre parce que tout le monde n'est pas développeur et donc la notion de "boucle" (sans parler de boucle shell...) est très abstraite voire totalement absente.
Heureusement qu'on applique pas le critère à d'autres disciplines sinon on se retrouverait avec des trucs du style "je ne suis pas mathématicien, donc je ne peux pas vérifier mes comptes bancaires, ces chiffres alignés sur un papier sont tout de même très abstraits"
Appliquer une opération pour chaque fichier (avec une commande commençant judicieusement habituellement par "for each") dans un ensemble donné avec une syntaxe shell donnée, c'est quand même pas la mer à boire. Évidemment si on parle un peu Anglais ça aide, j'avoue.
Je prétend pouvoir enseigner ça en très peu de temps à toute ma famille. Finallement à la reflexion, je n'aurais même pas besoin de leur parler de boucle. Et ce qu'ils auront appris, ils pourront facilement le transposer (j'espère!) à autre chose que du renommage de fichier.
Si on commence à faire peter une icone par opération imaginable pour les interfaces homme - machine, on aura bientôt droit à bien pire que Vista :/
Il faut se battre pour que l'informatique pour le grand public représente autre chose qu'un bouton à presser, avec pour seule alternative si le bouton n'a pas été prévu l'acquisition d'un nouveau bouton qui fera un peu plus que le précédent et aura un peu plus de bugs.
Si tu peux remplacer un long pipe recherchant des fichiers avec de multiples critères de ouf et exécutant des commandes arbitraires sur le résultat par une GUI, je dis bravo mais d'un autre coté je n'ose imaginer la gueule du clickodrome.
Si en plus tu peux récupérer l'équivalent de la commande et la mettre dans un scheduler pour exécution à heure fixe sur tel répertoire, ou encore pour exécution sur réception d'un appel téléphonique en provenance d'un numéro donné, alors là je m'inclinerais.
Mais encore une fois je doute qu'un truc utilisable dans ces domaines existe (et en tout cas l'effort pour développer une interface graphique dédié à un sous ensemble des problèmes de ce type est monstrueux par rapport à la résolution de l'ensemble complet avec des commandes CLI). Par exemple j'ai essayé un jour de programmer un réveil matin avec Automator et ITunes sous Os X. Verdict : strictement impossible à deviner comment faire, obligé de lire de longs tutoriaux et quand j'admire le résultat je ne vois pas en quoi c'est plus "simple"/"convivial"/"whatever" que de lancer un xmms dans un cron (ou tout autre player qui a le bon gout de se signaler à une instance déjà lancée), voir de balancer un "sleep $((8*3600)) ; mplayer muzikireveil.ogg" dans la première console qui passe par là avant de s'endormir. À vrai dire je pourrais apprendre à bien des personnes de mon entourage cette manière de faire, et vraisemblablement pas à configurer le clickodrome d'Os X.
Il faut arrêter de croire que les interfaces graphiques peuvent tout remplacer. Leur principale limite est l'impossibilité de combiner simplement des opérations élémentaires prises dans un ensemble ouvert avec des méthodes de combinaison elles-même prises dans un ensemble ouvert. Au mieux on pourra combiner un ensemble restreint et fixé d'opérations avec un ensemble restreint et fixé de manière de les combiner, sinon la GUI deviendra inutilisable, et en fait simplement inutile ; tout concepteur censé se retrouverait à concevoir un terminal interprétant un espèce de langage de haut niveau s'il devait résoudre ce pb.
En résumé les GUI ne sont bonnes qu'à résoudre ce pour quoi elles ont été conçues (et ce n'est pas une critique négative, certaines le font très bien !) et je trouverais toujours des exemples (par combinatoire, je pourrais en trouver des milliards) montrant des choses impossibles à faire sans clickodrome dédié et trivial avec une CLI. Bien évidemment il y a aussi des domaines dans lesquels utiliser une CLI est inenvisageable, du moins sans GUI associée.
Pourquoi encombrer son cerveau (et accessoirement son système) avec un nè clickodrome alors qu'il suffit de combiner une structure de boucle shell avec la commande standard de déplacement de fichiers pour obtenir la même chose. Et mieux, on peut faire autre chose que renommer les fichiers si on change la commande.
T'arrives pas à faire un alt tab avec la main droite en la dirigeant vers la gauche en remontant un peu le coude (pouce sur le alt) ? bon certes il faut déplacer sa main droite ...
Je ne suis qu'un simple droitier qui utilise sa souris à droite (et d'ailleurs j'ai été très étonné de lire "d'ouvrir instinctivement l'eau chaude aux robinets" car je n'avais jamais imaginé que le cerveau puisse mettre intuitivement en relation sa main la plus habile avec la température de l'eau) mais j'ai tout de même deux particularités :
Je jouais à des jeux style CS ou UT avec la souris dans la main gauche - parce encore auparavant je jouais à Doom donc sans souris et donc en dirigant mon personnage de la main droite, sur les touches fléchées du clavier, et que quand les jeux se sont mis à utiliser la souris j'avais trouvé plus facile de la faire passer à gauche que de changer la main qui me permettait de faire des déplacements instinctifs. J'étais pas trop trop mauvais à CS d'ailleurs :)
Je tiens mon couteau de la main gauche et ma fourchette de la main droite, parce que je trouve plus pratique de porter la fourchette à ma bouche avec la main droite et que j'ai la flemme de changer tout le temps de main.
Pourquoi pas mais je suis en général très reservé sur les fenêtre modales de confirmation pour neuneus. À trop forcer la dose, on obtient Windows Vista. Et des utilisateurs qui cliquent de manière incontrôlable sur "Oui" sans jamais rien lire.
Super, donc ce que tu proposes, c'est que à la sortie d'une release Debian le navigateur internet s'appelle Firefox (parce que bon mes braves gens, s'appeler Firefox ça à quand même plus de classe que IceWeasel, et que les pauvres petits Windowsiens vont être tout perdu pour on ne sait qu'elle raison mystique sinon), et trois ans après quand la MoFo aura décidé d'abandonner le support, que le soft change de nom tout seul au premier patch de sécu ?
En plus qu'est ce que c'est que cette histoire de fou qui consisterait à perdre son temps toutes les 5 minutes pour aller voir l'upstream et leur demander leur accord pour garder le nom du soft. Il va faloir faire ca avec tous les paquets ?
Ca ne résiste même pas 1/1000è de seconde au critère de l'île déserte.
Finalement, je ne comprend toujours pas ce que les gens qui critiquent ce changement de nom lui reproche. Debian a fait ce que la MoFo voulait (étant donné les contraintes propres de gestion des paquets de Debian). Tout le monde devrait être content.
Et note que je ne met personne dans le camp des "méchants"
Honnetement plus personne en a rien à foutre du fait qu'un navigateur sous Debian s'appelle Iceweasel et non pas Firefox. Surtout pas les débutants qui d'ailleurs prefererait même que le soft s'appelle "Navigateur Internet".
Là ou tu prouves que tu es a coté de la plaque c'est quand tu écris En passant, Debian™ est une marque déposée et défendue. Comme Firefox, Ubuntu, Mandriva, Fedora, Red Hat, Novell, Microsoft, Windows, Linux, etc.
Et alors ? Debian aurait raison, Xandros changerait le nom de sa "Debian NG" en autre chose. Et derrière tu viendrais nous dire quoi ? Que c'est n'importe quoi, qu'ils ont tords, qu'ils devrait plutôt organiser des gigantesques commités permettant à chaque nouveau upload de Xandros d'être béni par Debian et que Xandros conserve le nom de Debian NG ? Pragmatiquemet Xandros changerait simplement le nom de "Debian NG" en autre chose. Tout le monde trouverait tout ça très bien, fin de l'histoire.
Devine quoi : c'est exactement ce qui c'est passé dans le cas Firefox / Iceweasel. Vive l'autocontradiction.
Sauf que ce que je revendique, c'est aussi que le matos soit simple et fiable.
Il y a pas mal d'entreprises (qui n'ont rien à foutre des fenêtres en 3D qui tournent par exemple) qui serait ravies par un tel matos... sauf si ce que les revendeurs de soft leur proposent (Vista ? :p ) ne fonctionne pas dessus (ou à une vitesse qui les rendrait envieux en regardant des CPC 64), évidemment.
En passant ça pourrait permettre de réduire la conso électrique.
A partir d'une certaine version, les systèmes d'exploitation propriétaires ont choisi de séparer complètement l'affichage du reste, permettant de réinitialiser complètement l'affichage sans perdre le travail en cours. Les pilotes de cartes graphiques incluent cette gestion des exceptions, qui leur permet de redémarrer la carte graphique à la volée, en moins d'une seconde.
J'aurais tendance à considérer ça comme le résultat malheureux de l'ingénierie dirigée par les features, les perfs et le marketing (la qualité étant négligée à 99%, car ne faisant pas vendre). Un redémarrage isolé de sous-système a du sens en tant que mesure de sûreté dans un système critique avec des requirements de type "fail operational", au petit détail prêt que c'est le genre de chose tellement compliqué à faire correctement qu'il y a un risque de provoquer encore plus de défauts qu'auparavent (certains étant néanmoins récupérés correctement par le redémarrage, super!), ce n'est certainement pas une mesure à implémenter par défaut sur une CG grand public et le sous-système graphique associé d'OS grands publics, et une telle utilisation paliative me fait horreur : l'effort nécessaire à faire des produits qui fonctionnent correctement est sans doute radicalement inférieur à l'effort nécessaire à l'implémentation d'une telle usine à gaz permettant la reinitialisation de la CG.
Sauf bien sûr lorsque la qualité ne compte plus.
La chaîne de consommation a une grande part de responsabilité dans cet échec : en acceptant d'acheter des produits surdimensionnés pour ensuite faire du Word et du WWW, le consommateur déplace l'offre vers les perfs, les logiciels deviennent lent et bloated de part la pression marketing et l'absence de pression contraire au niveau des ressources dispo sur les plate forme d'exécution, le tout génère une usine à gaz qui tombe tout le temps en panne, et le point final à tout ceci est effectivement que des solutions horribles sont utilisées en guise de paliatif alors qu'elles n'auraient jamais du être employées dans ce domaine (et ne l'aurait jamais été dans un contexte sain).
Pour ma part, n'ayant jamais eu l'occasion d'admirer un système Linux sur lequel un X Window est stable avec les bordels proprio d'NVidia ou autres, j'évite dorénavant ce genre de config comme la peste. Un système dans lequel on paye pour des choses que l'on utilise jamais est une preuve d'inadéquation au besoin, voir un échec technique pur et simple.
Le logiciel a pour but de réaliser ce dont les militaires ne pouvaient que rêver jusqu'à présent : donner aux soldats le pouvoir de communiquer par réseau sans fil en temps réel avec des drones, contrôler à distance des robots de déminage, lancer des missiles guidés par laser sur des ennemis en mouvement et faire des téléconférences dans des tank lancés à pleine vitesse dans le brouillard de la bataille.
Ça a l'air puissant ce qu'ils font, mais à mon avis il est probable qu'ils pourraient à la place trouver chez un équipementier de telco militaire une solution existante qui fait 90% de ce qu'il sont en train de coder. (et qui en plus sera éprouvée)
Initialement prévu à plus de 30 millions de lignes il est maintenant reconnu que le nombre de lignes de code va dépasser largement les 60 millions.
J'ai un mauvais pressentiment quand à l'issue du projet dans ces conditions. Dans le meilleurs des cas le budget va explosé, ce qui vu les prévisions initiales va donner un coût... élevé :p
La seconde réflexion consiste à s'interroger sur la licence. Si le SOSCOE est basé sur Linux alors la GPL doit s'appliquer. Boeing en livrant le produit à son client doit donc obligatoirement lui fournir les sources. Plus drôle encore: Si ce système est vendu à d'autres pays (ce qui est probable à plus au moins long terme ne serais-ce que par souci d'interopérabilité avec les armées des pays amis) alors le source devra aussi leur être fourni.
La il faut arrêter l'alcool par contre.
Tu crois qu'ils vont coder 60 millions de lignes de plus dans le noyau ou dans un autre soft en GPL ?
Pour ton info il est parfaitement légal de faire du logiciel propriétaire en userspace sous Linux.
La plupart des gens qui vendent de l'embarqué sous Linux font ça.
Je te laisse avec tes extrapolations sur les références historiques déplacées ou autres incitations d'autant que contrairement à toi je saisis la nuance entre dictature et censure (l'une n'excluant pas l'autre).
Extrapolation de quoi s'il te plait ?
C'est pas moi qui ait calé un SS dans le titre de ton journal.
Bien sûr tu va me sortir que c'est par hasard et totalement justifié à la fois.
À voir la notation de mon commentaire, je suis ravis d'apprendre que les LinuxFRiens font en majorité l'amalgame entre Free, le régime Nazi, les dictatures, et j'en passe (du moins que ce genre d'amalgames ne les révoltent pas).
Enfin bon, j'ai peut-être loupé l'info comme quoi l'internaute jouant avec le feu a finalement été déporté et brulé dans un four, alors now je me tais.
Certes, mais on ne peut non plus imputer à Free le comportement inqualifiable de ces petits flics en manque d'aventures (je parle sous la condition que l'histoire rapportée soit bien réelle, mais quand bien même elle serait un peu exagérée je maintiendrais probablement mes propos).
Ratatium, qui crie à la dictature, ainsi que Bozo le clown qui fait des références déplacées à des sujets historiques d'une gravité incommensurablement plus grande (je sais, cette phrase ne veut rien dire :p), ne méritent pas plus le respect que Free dans cette affaire.
Et d'ailleurs, l'internaute à l'origine de tout ça fait bien vite l'amalgame entre fournisseur de transit et de producteur de contenu.
Quand à "les modérateurs vont devoir redoubler de vigilance", un minimum de bon sens suffit à conclure que non, et qu'il y a plutôt probablement une incitation à exactement le contraire.
Ouai c'est sympa (de toute manière dès que je vois du Python je trouve ça sympa :)
Bien sûr tout dépend du contexte.
Pour info la méthode décrite plus haut se place dans le contexte suivant (mais elle peut probablement être pratique dans d'autres) :
on a un assez gros build sys chargé de construire pleins de composant écrit en pleins de langages différents, constituant des logiciels dont nous ne sommes pas forcement l'upstream mais parfois si, avec des dépendances dans tous les sens et une pincées de flavours à gérer, sans compter qu'au final on upload dans de multiple repository (par version, ce qui est plus pratique que de postixer le numéro de version dans le nom dans notre cas et étant donné nos process de devel). Du fait de tout ce qui précède il y a plusieurs répertoires Debian possibles par composant. Enfin les paquets destinés à de la prod. (et dans une certaine mesure des paquets de dev. le sont aussi) sont buildés sur des machines dédiés dont l'environnement est contrôlé, car sur certains composants tiers essentiels on a un risque de changement du résultat du build en fonction des paquets installés sur l'hôte, donc pour obtenir un build reproductible une machine dédiée à cette tache est bienvenue.
Du coup le build et le packaging se font en multiples étapes (toutes automatisées) et ces aspects sont principalement gérés par le Debian Developer, et grâce à setuptools je ne me préoccupe généralement que d'un setup.py quand je fait un peu de Python :
D'ailleurs je ne sais pas très bien ce que python-distutils.mk fait des infos que je donne la dedans d'ailleurs. Il faudra que j'enquête un jour sur la question :p (à mon avis seul packages et ptet name sont utiles dans ce contexte)
[^] # Re: UN peu de calcul
Posté par Guillaume Knispel . En réponse au journal Le cryptage rentre dans les moeurs.. Évalué à 3.
[^] # Re: J'ai une explication!
Posté par Guillaume Knispel . En réponse au journal Tortoise SVN sous Gnome ? Et bien oui.... Évalué à 2.
J'avais décidé d'aller jusqu'au bout, histoire de voir si cette solution se revelait être finalement pratique et puissante ou pas.
Je suis ravi de voir qu'une solution plus simple existe pour ce problème précis, vu qu'il est assez courant. Le truc c'est qu'on est intrinsèquement limité par la liste des choix dispo. Difficile de régler le nivau du son avant de lancer la lecture audio sans passer par Automator par exemple (en restant dans le tout graphique bien sûr).
En fait je n'ai rien contre les IHM graphiques lorsqu'elles sont bien conçus et réalisent des opérations moyennement complexe et extrèmement courantes. Mais pour faire des choses assez complexes et potentiellement extensible sans abuser de son imagination (hors traitement intrinsèquement graphique), je constate habituellement qu'on obtient des usines à gaz, ou alors un truc à moitié fonctionnel et en tout cas pas évolutif, dans lequel on ne peut pas combiner des opérations existentes librement.
[^] # Re: J'ai une explication!
Posté par Guillaume Knispel . En réponse au journal Tortoise SVN sous Gnome ? Et bien oui.... Évalué à 3.
Heureusement qu'on applique pas le critère à d'autres disciplines sinon on se retrouverait avec des trucs du style "je ne suis pas mathématicien, donc je ne peux pas vérifier mes comptes bancaires, ces chiffres alignés sur un papier sont tout de même très abstraits"
Appliquer une opération pour chaque fichier (avec une commande commençant judicieusement habituellement par "for each") dans un ensemble donné avec une syntaxe shell donnée, c'est quand même pas la mer à boire. Évidemment si on parle un peu Anglais ça aide, j'avoue.
Je prétend pouvoir enseigner ça en très peu de temps à toute ma famille. Finallement à la reflexion, je n'aurais même pas besoin de leur parler de boucle. Et ce qu'ils auront appris, ils pourront facilement le transposer (j'espère!) à autre chose que du renommage de fichier.
Si on commence à faire peter une icone par opération imaginable pour les interfaces homme - machine, on aura bientôt droit à bien pire que Vista :/
Il faut se battre pour que l'informatique pour le grand public représente autre chose qu'un bouton à presser, avec pour seule alternative si le bouton n'a pas été prévu l'acquisition d'un nouveau bouton qui fera un peu plus que le précédent et aura un peu plus de bugs.
[^] # Re: J'ai une explication!
Posté par Guillaume Knispel . En réponse au journal Tortoise SVN sous Gnome ? Et bien oui.... Évalué à 6.
Si en plus tu peux récupérer l'équivalent de la commande et la mettre dans un scheduler pour exécution à heure fixe sur tel répertoire, ou encore pour exécution sur réception d'un appel téléphonique en provenance d'un numéro donné, alors là je m'inclinerais.
Mais encore une fois je doute qu'un truc utilisable dans ces domaines existe (et en tout cas l'effort pour développer une interface graphique dédié à un sous ensemble des problèmes de ce type est monstrueux par rapport à la résolution de l'ensemble complet avec des commandes CLI). Par exemple j'ai essayé un jour de programmer un réveil matin avec Automator et ITunes sous Os X. Verdict : strictement impossible à deviner comment faire, obligé de lire de longs tutoriaux et quand j'admire le résultat je ne vois pas en quoi c'est plus "simple"/"convivial"/"whatever" que de lancer un xmms dans un cron (ou tout autre player qui a le bon gout de se signaler à une instance déjà lancée), voir de balancer un "sleep $((8*3600)) ; mplayer muzikireveil.ogg" dans la première console qui passe par là avant de s'endormir. À vrai dire je pourrais apprendre à bien des personnes de mon entourage cette manière de faire, et vraisemblablement pas à configurer le clickodrome d'Os X.
Il faut arrêter de croire que les interfaces graphiques peuvent tout remplacer. Leur principale limite est l'impossibilité de combiner simplement des opérations élémentaires prises dans un ensemble ouvert avec des méthodes de combinaison elles-même prises dans un ensemble ouvert. Au mieux on pourra combiner un ensemble restreint et fixé d'opérations avec un ensemble restreint et fixé de manière de les combiner, sinon la GUI deviendra inutilisable, et en fait simplement inutile ; tout concepteur censé se retrouverait à concevoir un terminal interprétant un espèce de langage de haut niveau s'il devait résoudre ce pb.
En résumé les GUI ne sont bonnes qu'à résoudre ce pour quoi elles ont été conçues (et ce n'est pas une critique négative, certaines le font très bien !) et je trouverais toujours des exemples (par combinatoire, je pourrais en trouver des milliards) montrant des choses impossibles à faire sans clickodrome dédié et trivial avec une CLI. Bien évidemment il y a aussi des domaines dans lesquels utiliser une CLI est inenvisageable, du moins sans GUI associée.
[^] # Re: J'ai une explication!
Posté par Guillaume Knispel . En réponse au journal Tortoise SVN sous Gnome ? Et bien oui.... Évalué à 2.
Pourquoi encombrer son cerveau (et accessoirement son système) avec un nè clickodrome alors qu'il suffit de combiner une structure de boucle shell avec la commande standard de déplacement de fichiers pour obtenir la même chose. Et mieux, on peut faire autre chose que renommer les fichiers si on change la commande.
[^] # Re: Stallman sez
Posté par Guillaume Knispel . En réponse au journal Tortoise SVN sous Gnome ? Et bien oui.... Évalué à 2.
Donc les utilisateurs de GNU/Linux qui passent principalement par bash sont des Bashgnulinuxiens.
[^] # Re: Idem
Posté par Guillaume Knispel . En réponse au journal Gaucher, et l'informatique..... Évalué à 2.
# droitier et les couteaux
Posté par Guillaume Knispel . En réponse au journal Gaucher, et l'informatique..... Évalué à 4.
Je jouais à des jeux style CS ou UT avec la souris dans la main gauche - parce encore auparavant je jouais à Doom donc sans souris et donc en dirigant mon personnage de la main droite, sur les touches fléchées du clavier, et que quand les jeux se sont mis à utiliser la souris j'avais trouvé plus facile de la faire passer à gauche que de changer la main qui me permettait de faire des déplacements instinctifs. J'étais pas trop trop mauvais à CS d'ailleurs :)
Je tiens mon couteau de la main gauche et ma fourchette de la main droite, parce que je trouve plus pratique de porter la fourchette à ma bouche avec la main droite et que j'ai la flemme de changer tout le temps de main.
[^] # Re: Envoyer à tout mon carnet d'adresses...
Posté par Guillaume Knispel . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 2.
[^] # Re: Intelligence
Posté par Guillaume Knispel . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 4.
[^] # Re: Envoyer à tout mon carnet d'adresses...
Posté par Guillaume Knispel . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 4.
[^] # Re: Intelligence
Posté par Guillaume Knispel . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 4.
En plus qu'est ce que c'est que cette histoire de fou qui consisterait à perdre son temps toutes les 5 minutes pour aller voir l'upstream et leur demander leur accord pour garder le nom du soft. Il va faloir faire ca avec tous les paquets ?
Ca ne résiste même pas 1/1000è de seconde au critère de l'île déserte.
Finalement, je ne comprend toujours pas ce que les gens qui critiquent ce changement de nom lui reproche. Debian a fait ce que la MoFo voulait (étant donné les contraintes propres de gestion des paquets de Debian). Tout le monde devrait être content.
Et note que je ne met personne dans le camp des "méchants"
Honnetement plus personne en a rien à foutre du fait qu'un navigateur sous Debian s'appelle Iceweasel et non pas Firefox. Surtout pas les débutants qui d'ailleurs prefererait même que le soft s'appelle "Navigateur Internet".
Là ou tu prouves que tu es a coté de la plaque c'est quand tu écris
En passant, Debian™ est une marque déposée et défendue. Comme Firefox, Ubuntu, Mandriva, Fedora, Red Hat, Novell, Microsoft, Windows, Linux, etc.
Et alors ? Debian aurait raison, Xandros changerait le nom de sa "Debian NG" en autre chose. Et derrière tu viendrais nous dire quoi ? Que c'est n'importe quoi, qu'ils ont tords, qu'ils devrait plutôt organiser des gigantesques commités permettant à chaque nouveau upload de Xandros d'être béni par Debian et que Xandros conserve le nom de Debian NG ? Pragmatiquemet Xandros changerait simplement le nom de "Debian NG" en autre chose. Tout le monde trouverait tout ça très bien, fin de l'histoire.
Devine quoi : c'est exactement ce qui c'est passé dans le cas Firefox / Iceweasel. Vive l'autocontradiction.
[^] # Re: L'ingénieurie par les features, les perfs et le marketing.
Posté par Guillaume Knispel . En réponse au journal Fiabilité de Linux. Évalué à 5.
Il y a pas mal d'entreprises (qui n'ont rien à foutre des fenêtres en 3D qui tournent par exemple) qui serait ravies par un tel matos... sauf si ce que les revendeurs de soft leur proposent (Vista ? :p ) ne fonctionne pas dessus (ou à une vitesse qui les rendrait envieux en regardant des CPC 64), évidemment.
En passant ça pourrait permettre de réduire la conso électrique.
# L'ingénieurie par les features, les perfs et le marketing.
Posté par Guillaume Knispel . En réponse au journal Fiabilité de Linux. Évalué à 10.
J'aurais tendance à considérer ça comme le résultat malheureux de l'ingénierie dirigée par les features, les perfs et le marketing (la qualité étant négligée à 99%, car ne faisant pas vendre). Un redémarrage isolé de sous-système a du sens en tant que mesure de sûreté dans un système critique avec des requirements de type "fail operational", au petit détail prêt que c'est le genre de chose tellement compliqué à faire correctement qu'il y a un risque de provoquer encore plus de défauts qu'auparavent (certains étant néanmoins récupérés correctement par le redémarrage, super!), ce n'est certainement pas une mesure à implémenter par défaut sur une CG grand public et le sous-système graphique associé d'OS grands publics, et une telle utilisation paliative me fait horreur : l'effort nécessaire à faire des produits qui fonctionnent correctement est sans doute radicalement inférieur à l'effort nécessaire à l'implémentation d'une telle usine à gaz permettant la reinitialisation de la CG.
Sauf bien sûr lorsque la qualité ne compte plus.
La chaîne de consommation a une grande part de responsabilité dans cet échec : en acceptant d'acheter des produits surdimensionnés pour ensuite faire du Word et du WWW, le consommateur déplace l'offre vers les perfs, les logiciels deviennent lent et bloated de part la pression marketing et l'absence de pression contraire au niveau des ressources dispo sur les plate forme d'exécution, le tout génère une usine à gaz qui tombe tout le temps en panne, et le point final à tout ceci est effectivement que des solutions horribles sont utilisées en guise de paliatif alors qu'elles n'auraient jamais du être employées dans ce domaine (et ne l'aurait jamais été dans un contexte sain).
Pour ma part, n'ayant jamais eu l'occasion d'admirer un système Linux sur lequel un X Window est stable avec les bordels proprio d'NVidia ou autres, j'évite dorénavant ce genre de config comme la peste. Un système dans lequel on paye pour des choses que l'on utilise jamais est une preuve d'inadéquation au besoin, voir un échec technique pur et simple.
[^] # Re: Vente d'armement
Posté par Guillaume Knispel . En réponse au journal Future Combat Systems. Évalué à 6.
# mwairf
Posté par Guillaume Knispel . En réponse au journal Future Combat Systems. Évalué à 4.
Ça a l'air puissant ce qu'ils font, mais à mon avis il est probable qu'ils pourraient à la place trouver chez un équipementier de telco militaire une solution existante qui fait 90% de ce qu'il sont en train de coder. (et qui en plus sera éprouvée)
Initialement prévu à plus de 30 millions de lignes il est maintenant reconnu que le nombre de lignes de code va dépasser largement les 60 millions.
J'ai un mauvais pressentiment quand à l'issue du projet dans ces conditions. Dans le meilleurs des cas le budget va explosé, ce qui vu les prévisions initiales va donner un coût... élevé :p
La seconde réflexion consiste à s'interroger sur la licence. Si le SOSCOE est basé sur Linux alors la GPL doit s'appliquer. Boeing en livrant le produit à son client doit donc obligatoirement lui fournir les sources. Plus drôle encore: Si ce système est vendu à d'autres pays (ce qui est probable à plus au moins long terme ne serais-ce que par souci d'interopérabilité avec les armées des pays amis) alors le source devra aussi leur être fourni.
La il faut arrêter l'alcool par contre.
Tu crois qu'ils vont coder 60 millions de lignes de plus dans le noyau ou dans un autre soft en GPL ?
Pour ton info il est parfaitement légal de faire du logiciel propriétaire en userspace sous Linux.
La plupart des gens qui vendent de l'embarqué sous Linux font ça.
[^] # Re: Les utilisateurs de logiciels libres sont ...
Posté par Guillaume Knispel . En réponse au journal De l'arrivée de nouveaux utilisateurs d'origine Windows dans le monde du libre.... Évalué à 6.
# how should we think ?
Posté par Guillaume Knispel . En réponse au journal All your apple are belong to us. Évalué à 10.
8. Slogans and Taglines: You may not [...] “Think different.”
[^] # Re: Squeak like ?
Posté par Guillaume Knispel . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 2.
(en plus c'est libre :))
[^] # Re: no comment
Posté par Guillaume Knispel . En réponse au journal Halte à la cenSSure. Évalué à 1.
Extrapolation de quoi s'il te plait ?
C'est pas moi qui ait calé un SS dans le titre de ton journal.
Bien sûr tu va me sortir que c'est par hasard et totalement justifié à la fois.
À voir la notation de mon commentaire, je suis ravis d'apprendre que les LinuxFRiens font en majorité l'amalgame entre Free, le régime Nazi, les dictatures, et j'en passe (du moins que ce genre d'amalgames ne les révoltent pas).
Enfin bon, j'ai peut-être loupé l'info comme quoi l'internaute jouant avec le feu a finalement été déporté et brulé dans un four, alors now je me tais.
[^] # Re: Un mieux
Posté par Guillaume Knispel . En réponse au journal Halte à la cenSSure. Évalué à 5.
# no comment
Posté par Guillaume Knispel . En réponse au journal Halte à la cenSSure. Évalué à -2.
Et d'ailleurs, l'internaute à l'origine de tout ça fait bien vite l'amalgame entre fournisseur de transit et de producteur de contenu.
Quand à "les modérateurs vont devoir redoubler de vigilance", un minimum de bon sens suffit à conclure que non, et qu'il y a plutôt probablement une incitation à exactement le contraire.
[^] # Re: Je me dévoue...
Posté par Guillaume Knispel . En réponse à la dépêche Sortie de KDE 4.0. Évalué à 3.
Ceci étant, même si c'est le cas, autant ne pas l'affaiblir effectivement d'une telle façon ici aussi.
[^] # Re: hmhm
Posté par Guillaume Knispel . En réponse au journal py2deb : fabriquer des debs facilement .... Évalué à 1.
Bien sûr tout dépend du contexte.
Pour info la méthode décrite plus haut se place dans le contexte suivant (mais elle peut probablement être pratique dans d'autres) :
on a un assez gros build sys chargé de construire pleins de composant écrit en pleins de langages différents, constituant des logiciels dont nous ne sommes pas forcement l'upstream mais parfois si, avec des dépendances dans tous les sens et une pincées de flavours à gérer, sans compter qu'au final on upload dans de multiple repository (par version, ce qui est plus pratique que de postixer le numéro de version dans le nom dans notre cas et étant donné nos process de devel). Du fait de tout ce qui précède il y a plusieurs répertoires Debian possibles par composant. Enfin les paquets destinés à de la prod. (et dans une certaine mesure des paquets de dev. le sont aussi) sont buildés sur des machines dédiés dont l'environnement est contrôlé, car sur certains composants tiers essentiels on a un risque de changement du résultat du build en fonction des paquets installés sur l'hôte, donc pour obtenir un build reproductible une machine dédiée à cette tache est bienvenue.
Du coup le build et le packaging se font en multiples étapes (toutes automatisées) et ces aspects sont principalement gérés par le Debian Developer, et grâce à setuptools je ne me préoccupe généralement que d'un setup.py quand je fait un peu de Python :
from distutils.core import setup
setup(name='bla',
version='1.0',
description='Useful python libraries',
author='somebody',
author_email='tech@kikoo.tld',
url='http://kikoo.tld/',
packages=['kikoo', 'kikoo.Lol'],
)
D'ailleurs je ne sais pas très bien ce que python-distutils.mk fait des infos que je donne la dedans d'ailleurs. Il faudra que j'enquête un jour sur la question :p (à mon avis seul packages et ptet name sont utiles dans ce contexte)
[^] # Re: hmhm
Posté par Guillaume Knispel . En réponse au journal py2deb : fabriquer des debs facilement .... Évalué à 1.
Si j'arrive à le cloner je t'en enverrais une copie ;)