gaaaaaAab a écrit 1431 commentaires

oh ben pas de problème :)

Quand Apple retire un logiciel de son app store, ce n'est pas de la censure, et leur imposer de proposer une application serait une atteinte à leur liberté d'expression.

mais virer un truc parce qu'il ne 'respecte' pas une ligne de conduite, est une censure,

non. Pour censurer, il faut être un état. Debian n'a aucune obligation envers weboob. Et le retirer de leurs dépôt ne contrevient absolument pas à la liberté d'expression de weboob, qui peut continuer à s'appeler weboob autant qu'ils veulent. Ton appréciation est influencée par le fait que le paquet ait été accepté dans Debian à un moment, mais je pense que tu seras d'accord qu'un paquet qui n'est pas dans Debian (du soft proprio par exemple) ne peut pas invoquer une atteinte à sa liberté d'expression pour exiger d'être dans les dépôts de Debian.
Par contre, interdire à Debian de choisir quel paquet se trouve dans leur dépôt, ça, ça serait une atteinte à la liberté d'expression de Debian.

c'est pas vraiment du prior art, mais merci pour le lien. Je ne l'avais pas vu passer à l'époque, et c'est quand même une décision importante de la cour suprême US.

et aussi, on n'aime pas trop le spam

(et vive Lunex :D )

je dirais que oui. Je suis à peu près sûr d'avoir déjà vu passer des appels à prior art à l'international pour contester des brevets logiciels aux USA.
Et j'ai trouvé cet article (en anglais), qui cite la section 102 du chapitre 10 du titre 35 du code US

Pour ce qui concerne l'étranger:

A person shall be entitled to a patent unless—

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this or a foreign country, before the invention thereof by the applicant for patent, or

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of the application for patent in the United States, or
(…)

traduction grossière:

un brevet pourra être délivré à une personne à moins que:
(a) l'invention ait été connue ou utilisée par d'autres dans ce pays, ou brevetée ou décrite dans une publication imprimée dans ce pays ou un pays étranger, avant l'invention par le candidat au brevet, ou
(b) l'invention a été brevetée ou décrite dans une publication imprimée dans ce pays ou un pays étranger ou d'utilisation publique ou en vente dans ce pays depuis plus d'un an avant la date de dépôt de la demande de brevet aux Etats-Unis
(…)

heu … as-tu lu l'article en entier ?

je ne sais pas avec qui tu as été amené à travailler, mais j'ai une expérience différente. Mon code est meilleur quand on bosse à plusieurs dessus.

ok, j'imagine que c'est un peu gênant (mais c'est pas non plus le bug du siècle). J'ai essayé de trouver un rapport de bug qui parlerait de ça mais je ne tombe sur rien d'intéressant sur le sujet. Faudrait chercher plus spécifiquement sur les rapports de bugs de ta distrib, parce que le bug n'est pas forcément chez vlc.

Autre exemple, exécutez dans un terminal : " touch foo.mp4 ; vlc foo.mp4 & "

chez moi, ça crée le fichier vide foo.mp4, et puis ça lance vlc (qui ne lit rien puisque le fichier est vide), ce qui m'a l'air d'être le comportement attendu. Il se passe quoi chez toi ?

En fonction de ta distribution Linux, ça va varier, mais il faut que tu installes un paquet qui va s'appeler quelque chose ressemblant à libc-dev. Ce paquet contient tous les fichiers d'en-têtes relatifs à la librairie standard du C. Normalement, ça va les installer à un endroit où ton gcc devrait pouvoir les trouver sans que tu aies besoin d'en faire plus.

ok, on a des profiles de joueurs très différents. Ce ne sont les pas jeux vidéos en général qui te retiennent, mais ces jeux très précis dans lesquels tu t'investis, et que te ne peux pas (ou ne veux pas) remplacer par d'autres jeux.

The Secret World

c'est vrai que je n'ai pas réussi à le faire tourner. Enfin si, mais à 10 FPS avec des bugs de textures (ou peut-être plutôt de shaders) rigolos, donc pas jouable. Mon dernier essai remonte à quelques années, wine le gère peut-être mieux maintenant.

the Witcher 3?

ouais, j'étais un peu déçu qu'ils ne fassent pas une version Linux alors qu'ils l'ont fait pour le 2. Après, je triche un peu aussi, je ne joue pas exclusivement sur PC, donc je peux, à l'occasion, jouer à des trucs qui ne sont pas sous Linux.

effectivement :)

Vu où tu as posté dans l'arborescence, je ne suis pas sûr, mais je le prends pour moi :)

Non on ne s'en fout pas du nombre d'utilisateur sous Linux.

je n'ai pas dit que je m'en fous complètement, mais que je m'en fous un peu. Je ne nie pas qu'il y a des avantages à ce que plus de monde utilise Linux. Mais ce n'est pas non plus l'alpha et l'omega. Un des OS les plus déployés dans le monde est un OS libre, c'est MINIX, présent dans le ME de toutes les puces Intel depuis une dizaines d'années. Super …

On pourrait aussi trouver des ordinateurs grand public avec Linux pré installés

Il y a moins de choix que pour du Windows, mais ça se trouve.

Désolé, mais j'aime jouer,

moi aussi

et nombre de jeux ne sont dispo que sous windows

et nombres de (très bons) jeux sont dispos aussi sous Linux. Et avec le travail que valve fait sur proton en ce moment, le choix augmente. Comme tu dis que tu n'as pas le temps, tu ne peux pas jouer à tous les bons jeux. Alors est-ce que c'est si grave de ne pas pouvoir jouer à quelques titres, sachant que ça ne veut pas dire que tu ne peux pas jouer à d'autres bon jeux ? Le seul problème que je vois, c'est si tu joues en multi avec un groupe de potes, et qu'ils choisissent systématiquement des exclus windows. À toi de voir ce à quoi tu accordes le plus de valeur entre Linux et quelques jeux sous Windows.

je dois dire que je n'ai même pas cherché à installer linux sur mon dernier portable, j'ai plus le temps…

perso quand j'achète du matos (fixe ou portable), je prends un peu de temps pour vérifier la compatibilité. Mais c'est vrai que de temps en temps, il y a un petit truc qui coince (il faut dire je suis sur une Debian quelque part entre du sid et du unstable avec un chouille de devuan, et parfois avec un noyau compilé du git de Linus, alors je cherche un peu :D )

Le jour où Linux perce sur le desktop, fini le Windows crasseux imposé au boulot, et ça, ça me changera ma vie :)

ok, ben retiens pas ta respiration hein :)

imposé au boulot

mauvais boulot, changer boulot. Ça sonne un peu trollesque (et j'admets, ça l'est un peu), mais c'est possible de trouver des environnements de travail où on peut bosser avec un poste sous Linux. Si ça ne fait pas partie de tes critères discriminants pour accepter un emploi, c'est un peu ton choix.

Je pense qu'on aurait tort de rejeter ce genre de choses car ils utilisent des logiciels qu'on aime pas pour diverses raisons. Si par effet de bord cela en fait bénéficier tout le monde. Pourquoi pas.

Tout à fait. Pourquoi pas. Je rappelle que je ne commente pas dans le vide, mais dans le contexte des commentaires qui ont initiés la conversation.

Mais pour revenir sur le journal, si on n'a pas besoin de logiciels type ce que fait Adobe, et si on n'a aucune intention de leur en acheter s'ils les portent sous Linux, je pense qu'il ne faut pas demander à Adobe de porter juste parce qu'on pense que ça serait cool que ça soit dispo sous Linux. Et je me demande dans quelle mesure ça ne serait pas contre productif.

C'est clair que je m'exprime pas clairement :)

Je parle de l'erreur qui consisterait à se focaliser sur la présence de Linux sur le desktop juste pour avoir Linux sur le desktop. On sait où ça mène, vu que c'est ce qui se passe sur mobile avec Android. Certes c'est mieux d'avoir Android que rien, mais bon. Et donc, si on n'arrête de se focaliser sur Linux pour Linux, et qu'on regarde la façon dont les utilisateurs peuvent prendre le contrôle de leurs outils, je préfère du logiciel libre sous Windows à du logiciel proprio sous Linux, en tout cas, à court/moyen terme pour les couches logicielles les plus proches de l'utilisateur (et hop, je reviens sur le sujet du journal). À la réflexion, je ne pouvais pas laisser de côté la question du critère "Linux sur le desktop" (comme je l'ai fait dans mon premier commentaire) si je veux un peu expliquer mon point de vue sur le portage éventuel des logiciels d'Adobe sur Linux.

Maintenant, Renault présente un point de vue intéressant sur la question juste au dessus qui montre qu'effectivement, pousser Linux sur le desktop, ce n'est pas si hors sujet que ce que j'ai pu écrire.

Quand tu illustres les commandes avec l'affichage splité (toi en bas à droite et le terminal au milieu), ça serait bien je pense si tu ramenais tes exemples plus vers le milieu de l'image. Là, sous firefox, si je passe ta vidéo en plein écran, et que je fais pause, le lecteur de youtube affiche un bandeau avec le nom de la vidéo par dessus tes lignes de commandes. Et plus généralement, d'un point vue ergonomique, je pense que c'est bien que ce que tu veux présenter soit au centre de l'image.

Tiens, question subsidiaire, parce qu'ici, on aime pinailler. Ta machine tourne sous Linux ou sous MacOs ? (ou tu as appelé ta machine MacBook mais c'est pas un MacBook ? ;) )
Ah, je crois que j'ai ma réponse à 8:30 …

pas assez de choix de logiciels

heu … est-ce que je comprends bien si je reformule "pas assez de choix" en "couverture insuffisante du spectre des besoins logiciels". Parce du choix, il y a en a, c'est même une critique régulièrement faite à l'écosystème Linux/logiciel libre.

Oui. Avoir le choix, ça compte, il me semble. En tout cas ça compte pour moi, qui utilise beaucoup de LL, mais pas que ça.

oui, je forçais un peu le trait pour souligner que la présence de Linux sur le desktop, c'est une métrique, mais j'ai du mal à voir ça comme un objectif vraiment pertinent. Dans un monde fictif où tout le monde aurait migré pour utiliser une pile proprio sous Linux, on aurait 100% de Linux sur le desktop, et on serait pas plus avancé.

perso, je me fous un peu que Linux perce ou pas sur le desktop, mais je met ça de côté.

Une solution pour favoriser la migration, c'est que des logiciels proprio soient dispos sous Linux, une autre, c'est que les logiciels de référence soient des logiciels libres et donc aussi disponibles sous Linux. La première solution revient à transformer Linux en OS "normal" où, finalement, que l'os soit libre n'a aucune espèce d'importance. Est-ce que ce serait vraiment un progrès si tous les utilisateurs desktop migraient sous Linux pour utiliser leurs applis proprios ?
(question rhétorique). Bref, adobe, s'ils veulent publier du logiciel libre sous Linux, c'est cool. S'ils veulent vendre leur soft proprio sous Linux, c'est cool aussi, mais moi, je ne leur demande pas.

Rechecher

ah ben on écrit en verlan maintenant, bravo :)

À noter que les raccourcis avec Ctrl sont dans readline (je ne connaissais pas ceux avec esc, possible qu'ils en viennent aussi). De ce fait, tous les outils CLI liés avec libreadline héritent de tous ces raccourcis (et pour les autres, il y a rlwrap).

j'utilise pas Ctrl-d, mais beaucoup Ctrl-w, Ctrl-r, et Ctrl-c pour tuer la ligne en cours. J'aime bien Ctrl-t, mais à moins d'avoir une latence tellement monstrueuse que ça vaut le coup d'économiser des pressions de touches, c'est plus mignon qu'autre chose.

code mon_flux | sed -e "s/toto\(.*\)tata/\1/g"

alors, c'est pas le meilleur exemple, parce que comme * est greedy, le /g ne sert à rien. En l'état, la regex ne fait probablement pas ce que tu crois.

Oups, j'avais oublié sur quel site je postais ce commentaire :)

;-)

xargs, grep et sed ne doivent avoir aucun secret pour toi

J'ajouterais find dans la liste.

Bien connaître sed, c'est cool, mais maîtriser sed, c'est une autre paire de manche. On peut déjà faire des trucs très puissants sans jamais savoir qu'on peut utiliser le hold_space. Et pouvoir écrire (ou lire) une calculatrice à précision arbitraire en sed ne me parait pas indispensable (et la doc qui va avec)

PS: Il n'est pas impossible que ce commentaire n'existe que pour souligner à quel point sed, c'est de la balle :)

pour poster du code, essaie d'utiliser les balises décrites dans l'aider mémoire en dessous de la boite de rédaction. Pour ton code, la partie de création d'un nouveau dictionnaire m'a l'air correcte

dico_inv ={}
for key in MORSE_CODE_DICT:
    item = MORSE_CODE_DICT[key]
    dico_inv[item] = key

la suite, par contre, ça coince. Regarde ce que donne le code suivant:

for key in (encodedmess):
    print key

ce n'est probablement pas ce que tu voulais faire. encodedmess est déjà une liste.

Et ta ligne de print, je n'ai pas regardé dans le détail, mais le fait que tu n'utilises pas dico_inv que tu viens de créer est un bon indice que c'est probablement pas ça.

list comprehension et dict comprehension, du bon python comme on aime :)

En dehors des problèmes de majuscules/minuscules, un petit bug quand même, il faut remplacer C[Z] par MORSE_CODE[Z]

Tu es écoutable, tu es traçable, donc tu es écouté et tu es tracé.

puisque je suis mortel, je suis mort ?

si la question est pour moi, j'utilise xdm